Discrepancy with pytz

[alexprengere]

Hello,
First of all, thank you so much for creating zoneinfo, and getting it merged in the upcoming Python release. I was not sure if I should open this here or on the Python bug tracker.

I found a discrepancy between pytz and zoneinfo running a test suite on one of my projects after migrating to zoneinfo. This test case was built using values described in this blog post, to test that I properly used normalize at some point.

I am actually fairly confident this is not a bug in zoneinfo, but since I am not an expert, here you go.

>>> t = 2002, 10, 27, 1, 0
>>> z = 'America/New_York'
>>> pytz.timezone(z).localize(datetime(*t)) - datetime(*t, tzinfo=ZoneInfo(z))
datetime.timedelta(seconds=3600)  # I would have expected timedelta(0)

Edit: this was tested with backports.zoneinfo==0.2.0 and pytz==2020.1 on CPython 3.7.5.

[pganssle]

This is because 2002-10-27T01:00 is an ambiguous datetime. zoneinfo supports PEP 495 and pytz does not. pytz defaults to interpreting ambiguous datetimes as the "standard" side of the transition (as was recommended by the docs prior to PEP 495), whereas PEP 495-compatible time zone providers default to using whichever offset was applied chronologically first (which is usually the DST side).

So this is the expected behavior. There's no generic way to make the behavior identical, because some zones have negative DST, but excepting those rare zones, setting fold=1 on your datetime will give you the same result:

>>> dt = datetime(2002, 10, 27, 1, 0)
>>> print(pytz.timezone("America/New_York").localize(dt))
2002-10-27 01:00:00-05:00
>>> print(dt.replace(fold=1, tzinfo=ZoneInfo("America/New_York")))
2002-10-27 01:00:00-05:00

More on ambiguous datetimes in this blog post.

Thanks for using zoneinfo! Feel free to report bugs here or on bugs.python.org, either is fine.