stub42 / pytz

pytz Python historical timezone library and database
MIT License
352 stars 93 forks source link

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

Open abhikeny opened 1 month ago

abhikeny commented 1 month ago

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:

Thanks in advance for looking into this.

abhikeny commented 1 month ago

More REPL traces:

bxparks commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.