Wrong DST for dates after year 2038

[amiart]

When I create UTC date after 2038 year and then change the timezone to eg. 'Europe/Warsaw' the DST is wrong.

For example, in june Warsaw is in GMT+2 time zone so when I set UTC time to 10:00 the time in Warsaw should be 12:00.

Code to reproduce bug:

Date before 2038, gives 12:00. everything OK:

>>> utc_dt = datetime(2037, 6, 1, 10, 0, 0, tzinfo=pytz.utc)
>>> utc_dt
datetime.datetime(2037, 6, 1, 10, 0, tzinfo=<UTC>)
>>> loc_dt = utc_dt.astimezone(timezone('Europe/Warsaw'))
>>> loc_dt
datetime.datetime(2037, 6, 1, 12, 0, tzinfo=<DstTzInfo 'Europe/Warsaw' CEST+2:00:00 DST>)

Date after 2038, should be 12:00, but gives 11:00:

>>> utc_dt = datetime(2038, 6, 1, 10, 0, 0, tzinfo=pytz.utc)
>>> utc_dt
datetime.datetime(2038, 6, 1, 10, 0, tzinfo=<UTC>)
>>> loc_dt = utc_dt.astimezone(timezone('Europe/Warsaw'))
>>> loc_dt
datetime.datetime(2038, 6, 1, 11, 0, tzinfo=<DstTzInfo 'Europe/Warsaw' CET+1:00:00 STD>)

[stub42]

pytz only understands the 'old' IANA timezone database binary format and has a Y2038 bug. Work on fixing this should probably go into Python core, adding a tzfile implementation that supports the modern format.

[kurt-rhee]

I also have this issue.

[pganssle]

Work on fixing this should probably go into Python core, adding a tzfile implementation that supports the modern format.

For anyone finding this thread later: this has been done. The zoneinfo module was added in Python 3.9 and there is a backport available to Python 3.6.

[septatrix]

Any recent progress towards supporting the newer format or working with the zoneinfo module?

[ClementJeannesson]

Same issue here.