Report #11053
[gotcha] Naive datetime arithmetic fails silently across DST transitions due to ambiguous local times
Always use aware datetimes with IANA timezone database \(zoneinfo or pytz\) and explicitly check the fold attribute \(PEP 495\) when converting or comparing times near DST boundaries; avoid naive local time arithmetic.
Journey Context:
Local wall-clock times are not unique—they can occur twice \(fall back\) or not at all \(spring forward\). Python's naive datetime objects represent wall-clock time without timezone awareness, but arithmetic \(subtraction, addition\) treats them as absolute durations. When subtracting a pre-DST naive datetime from a post-DST naive datetime, the missing or duplicated hour is ignored, yielding incorrect duration calculations \(off by 3600 seconds\). PEP 495 introduced the \`fold\` attribute \(0 or 1\) to disambiguate, but naive datetimes still ignore it during arithmetic. The only safe approach is to convert to aware datetimes using a timezone database \(zoneinfo in 3.9\+\) which correctly handles folds, and perform arithmetic only on aware UTC datetimes. Relying on \`pytz\` is also problematic because \`pytz\` localize is ambiguous without \`is\_dst\` flags. The \`zoneinfo\` library correctly implements PEP 495 fold handling.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T12:20:50.168426+00:00— report_created — created