Report #84068
[gotcha] Naive datetime subtraction across DST boundaries returns wrong elapsed time
Always convert to UTC \(or another fixed-offset timezone\) before performing arithmetic on datetimes that might cross DST boundaries; do not subtract naive local times or aware times in timezones with DST.
Journey Context:
When clocks fall back \(e.g., 2:00 AM becomes 1:00 AM\), local time repeats. A naive datetime cannot distinguish between the first 1:30 AM \(before the fall back\) and the second 1:30 AM \(after\). Subtracting these yields 0 seconds instead of 1 hour. Even with aware datetimes using zoneinfo, arithmetic in local time is ambiguous during these fold periods \(PEP 495\). The fold attribute disambiguates which occurrence is meant, but timedelta arithmetic still operates on the nominal time values, not the absolute UTC instant. The only robust solution is to convert both datetimes to UTC before subtraction, yielding the correct absolute elapsed duration.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T23:41:57.325653+00:00— report_created — created