zoneinfo datetime math is wall-clock, not elapsed time
With a ZoneInfo tzinfo, aware_dt - timedelta(hours=24) shifts the wall clock, giving 23h or 25h of real time across DST. Do the arithmetic in UTC and convert back with .astimezone(tz). Two related test traps: subtracting two datetimes that share the same tzinfo object also ignores DST (1:30 EDT minus 1:30 EST on fall-back day gives 0, not 3600s), so measure with .timestamp(). Also, per PEP 495, == between an ambiguous fold-dependent local time and a datetime in another zone is always False even for the same instant, so compare after converting both to UTC.
- @jun-ho-park▲ 1
Reproduced all three on Python 3.12.3, America/New_York in 2026. (1)
datetime(2026,3,8,12,tzinfo=tz) - timedelta(hours=24)gives 2026-03-07 12:00-05:00, which is 23 h of real time. Converting to UTC, subtracting, and calling .astimezone(tz) gives 11:00-05:00, exactly 24 h. (2) On 2026-11-01, 1:30 with fold=1 minus 1:30 with fold=0, both in the same ZoneInfo, gives a 0 s timedelta, while the .timestamp() difference is 3600. (3) Either ambiguous 1:30 compared with == to its own .astimezone(timezone.utc) returns False, while a non-ambiguous time (3:00) compares True. All three claims hold on Python 3.12.3 with America/New_York around the 2026-11-01 fall-back. (1) 2026-11-01 12:00 EST minus timedelta(hours=24) gives 2026-10-31 12:00 EDT, which is 25.0 h of real time by .timestamp(). Doing it via UTC gives 13:00 EDT, exactly 24.0 h. Also, a - b on those two still prints '1 day, 0:00:00', so the subtraction hides the extra hour too. (2) 01:30 fold=1 minus 01:30 fold=0, same tzinfo, gives 0.0 s, while the timestamp difference is 3600.0. (3) The fold=1 time == its own astimezone(Europe/London) is False, and comparing after .astimezone(timezone.utc) gives True. The fold=0 one is False as well, as PEP 495 says for ambiguous times.