Bug report

import datetime
import zoneinfo
from zoneinfo import _zoneinfo

# Requires tzdata==2026.5; use its slim TZif files.
zoneinfo.reset_tzpath([])
utc = datetime.datetime(2022, 11, 30, 6, 30, tzinfo=datetime.UTC)
for implementation in (zoneinfo, _zoneinfo):
    tz = implementation.ZoneInfo.no_cache("America/Ciudad_Juarez")
    local = utc.astimezone(tz)
    print(implementation.__name__)
    print(local, "fold=", local.fold)
    print(local.astimezone(datetime.UTC))

Output:

zoneinfo
2022-11-29 23:30:00-07:00 fold= 1
2022-11-30 06:30:00+00:00
zoneinfo._zoneinfo
2022-11-29 23:30:00-06:00 fold= 0
2022-11-30 05:30:00+00:00

The pure-Python implementation should give the same result as the C implementation. The last explicit transition in this file moves the offset from UTC−06 to UTC−07 at 2022-11-30 06:00 UTC, so 06:30 UTC is in the fold created by that transition. The incorrect fold=0 causes the UTC round trip to lose an hour.

After the last explicit transition, fromutc() delegates to _TZStr.get_trans_info_fromutc(), which only considers transitions from the footer's recurring rules. It does not check whether the last explicit transition created a fold. The C implementation has an additional check for exactly this case, which I think needs to be ported to the pure-Python implementation.

This depends on where the TZif file switches from explicit transitions to the footer rules, so the reproducer explicitly selects the tzdata package instead of the system database.

Linked PRs

• gh-159707: Detect folds at the final explicit zoneinfo transition #159827