Why is pytz.timezone.localize returning different zones for the same month/date value in 2 different years?

[abhikeny]

Why is the same date (May 2nd) in 2 different years (2019 vs. 2098) being converted to PDT in 2019 but PST in 2098?

>>> from pytz import timezone
>>> from dateutil.parser import parse
>>> tz_obj = timezone("US/Pacific")
>>> effective_start = tz_obj.localize(parse(f"5/2/2019 12:00:00 AM"))
>>> effective_end = tz_obj.localize(parse(f"5/2/2098 12:00:00 AM"))
>>> effective_start
datetime.datetime(2019, 5, 2, 0, 0, tzinfo=<DstTzInfo 'US/Pacific' PDT-1 day, 17:00:00 DST>)
>>> effective_start.isoformat()
'2019-05-02T00:00:00-07:00'
>>> effective_end
datetime.datetime(2098, 5, 2, 0, 0, tzinfo=<DstTzInfo 'US/Pacific' PST-1 day, 16:00:00 STD>)
>>> effective_end.isoformat()
'2098-05-02T00:00:00-08:00'

Seems like some strange behavior in this package's timezone().localize() function, since the output of dateutil's parser.parse() does not really change except for the year which is passed in.

Environment:

• Python: 3.11.2
• python-dateutil==2.8.2
• pytz==2024.2

Thanks in advance for looking into this.

[abhikeny]

More REPL traces:

• Showing dateutil.parser.parse returns same data:

>>> parse("2036-05-02 07:00:00.000000 +00:00")
datetime.datetime(2036, 5, 2, 7, 0, tzinfo=tzutc())
>>> parse("2037-05-02 07:00:00.000000 +00:00")
datetime.datetime(2037, 5, 2, 7, 0, tzinfo=tzutc())
>>> parse("2038-05-02 07:00:00.000000 +00:00")
datetime.datetime(2038, 5, 2, 7, 0, tzinfo=tzutc())

• Showing that passing tz_obj causes discrepancy from 2038:

>>> from pytz import timezone
>>> tz_obj = timezone("US/Pacific")
>>> parse("2036-05-02 07:00:00.000000 +00:00").astimezone(tz_obj)
datetime.datetime(2036, 5, 2, 0, 0, tzinfo=<DstTzInfo 'US/Pacific' PDT-1 day, 17:00:00 DST>)
>>> parse("2037-05-02 07:00:00.000000 +00:00").astimezone(tz_obj)
datetime.datetime(2037, 5, 2, 0, 0, tzinfo=<DstTzInfo 'US/Pacific' PDT-1 day, 17:00:00 DST>)
>>> parse("2038-05-02 07:00:00.000000 +00:00").astimezone(tz_obj)
datetime.datetime(2038, 5, 1, 23, 0, tzinfo=<DstTzInfo 'US/Pacific' PST-1 day, 16:00:00 STD>)

[bxparks]

pytz does not support dates after 2038-01-19 03:14:07 UTC, as far as I know. See https://en.wikipedia.org/wiki/Year_2038_problem

[abhikeny]

Oh! That's interesting, @bxparks . Thanks for sharing this detail.
If Python's built-in zoneinfo module does not have that issue, is there any reason that pytz can't be updated to handle the y2038 problem?

[bxparks]

Aside from changing to the 64-bit version of TZDB, tracking down every reference to the 32-bit epochseconds, updating all the tests, and verifying that everything is 100% backwards compatible and works correctly, I suppose no reason at all, except for time and motivation from the pytz maintainer (a single person I believe).

The Y2038 problem for pytz is a long-standing issue, see #31 for example. You should consider migrating to zoneinfo if this problem is important for you.