Fix compatibility with non-pytz tzinfo objects

[danpalmer]

My understanding of timezone code in Python is fairly limited, so please treat this as a proposal or a discussion point – it certainly needs review from someone with more understanding of the timezone ecosystem than myself.

That said, I believe what has happened here is that python-libfaketime is depending on pytz specific functionality – the zone attribute. From my exploration of the pytz and dateutil codebases, it looks like the tzname method returns the same data. My understanding of the difference between pytz and dateutil is that with the former, tzinfo objects know about their owning datetime, whereas in the latter they don't (I could be wrong on this!).

This PR uses these assumptions to change fake_time to call tzname(datetime_spec) instead of using .zone in the case that the datetime_spec is a datetime. A test is included to prevent regressions, although a review on whether this is the best wording of this test would be appreciated.

This change fixes behaviour of python-libfaketime in a codebase that makes extensive use of dateutil and does not use pytz, where previously we had many test failures.

[adamchainz]

Seems like pytz's zone attr is used for tzname(): https://github.com/stub42/pytz/blob/7b1a844c8ecf2996142ac0eb32201b676e9dcb9a/src/pytz/tzinfo.py#L466-L497 .

[danpalmer]

Ah good spot @adamchainz. Looks like this should be strictly more compatible, and should allow for more edge cases in that case.

[danpalmer]

After further testing there's another edge case that this doesn't account for. It's possible to have an un-named timezone, i.e. just an offset. These return None from tzname, and then cause a serialisation exception when we try to put the timezone_str into the environment.

I believe this would have been the case before this PR anyway, so I don't believe this is a regression and this PR could still be merged.

I'll raise an issue for this behaviour. We aren't blocked on it so I probably won't get to fixing it myself for now I'm afraid.

[simon-weber]

looks reasonable to me. thanks!

[danpalmer]

@simon-weber thanks for this! Is it possible to get this shipped as a release?

[simon-weber]

yup, I should be able to get to it within a day or two.

[simon-weber]

released in 2.0.0: https://pypi.org/project/libfaketime/2.0.0/