DST changes broken in future (2038 and beyond)

[direx]

I just noticed that DST changes are not calculated at all for dates beyond (and including) 2038.

Example:

>>> tz=pytz.timezone("Europe/Berlin")
# This is correct:
>>> tz.localize(datetime.datetime(2037,5,1,23,59,59))
datetime.datetime(2037, 5, 1, 23, 59, 59, tzinfo=<DstTzInfo 'Europe/Berlin' CEST+2:00:00 DST>)
# This is wrong:
>>> tz.localize(datetime.datetime(2038,5,1,23,59,59))
datetime.datetime(2038, 5, 1, 23, 59, 59, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>)
>>> pytz.__version__
'2019.3'

I have tested a few timezones and this bug seems to affect all of them.

[Brian Park (xparks)]

I believe this is related to this question from 2015:
https://answers.launchpad.net/pytz/+question/262216
where it is stated that pytz as of 2015.6 supports only v1 format, which uses 32-bit integers, which means that it cannot support dates beyond 2038-01-19T03:14:07Z.

It would be useful to know when (or if) pytz will support dates beyond 2038. As the current date gets ever closer to 2038, more people will have this same question.

[Stuart Bishop (stub)]

Any work on adding support for modern tzfile formats should be added to the Python Standard Library. It has been discussed and generally agreed on the Python lists, but I don't know if anyone has allocated the time to do the work.

[direx (direx.1)]

If pytz cannot handle dates beyond 2038 then an exception should be raised for such dates instead of working with wrong information.

Right now people feel save and do calculations based on wrong times. I think it would be better to warn people about the missing y2k38 support in pytz.

[Stuart Bishop (stub)]

Behavior beyond 2038 is defined, per the original tzdata file format. Changing the behavior to raise exceptions with this date range is unfortunately backwards incompatible, which is critical for a long lived library like pytz. This sort of behavior change can happen when functionality is added to Python core (or better yet, support for later years).

Its worth noting that conversions of future timestamps are always a guess, as timezone rules change. It is highly likely that conversions made for dates beyond 2038 using any given DST aware timezone will be incorrect, as it is quite likely that the rules will change over the next few decades. But yes, we are getting closer and the probability will drop the closer we get.