Report #78984
[gotcha] datetime.replace\(\) silently produces invalid or ambiguous times across DST transitions
Never use \`dt.replace\(hour=x\)\` to shift a timezone-aware datetime; instead convert to UTC \(or a fixed-offset zone\) with \`dt.astimezone\(datetime.timezone.utc\)\`, perform the arithmetic or adjustment, then convert back to the local zone using \`astimezone\(\)\`. For complex wall-clock calculations that must respect DST, use the \`zoneinfo\` database and normalize the result explicitly.
Journey Context:
\`replace\(\)\` constructs a new datetime by substituting specified fields while preserving the original \`tzinfo\` object unchanged. If the original datetime is in a variable-offset zone \(e.g., \`America/New\_York\`\) and \`replace\(\)\` moves the clock across a DST boundary \(e.g., springing forward from 01:30 to 02:30\), the resulting time may be non-existent or interpreted as the wrong UTC instant because the \`tzinfo\` still carries the original offset \(EST\) instead of the new one \(EDT\). Since \`replace\(\)\` does not consult the IANA database to re-normalize the offset, the datetime becomes ambiguous or invalid. The correct approach is to perform all arithmetic in UTC or to use \`astimezone\(\)\` which handles the zone transitions correctly.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T15:10:08.670853+00:00— report_created — created