Report #62431
[gotcha] OverflowError when applying timezone offset to datetime.min or datetime.max
Avoid using datetime.min or datetime.max as sentinel values for timezone-aware datetimes. Use None or a custom sentinel object \(e.g., a unique private class instance\) to represent 'infinity' or 'no date'. If you must use these constants, ensure you only convert to UTC \(offset 0\) or clamp the value before localizing.
Journey Context:
datetime.min \(year 1\) and datetime.max \(year 9999\) are the absolute limits of the datetime representation. When you call .replace\(tzinfo=...\) or .astimezone\(\) on these objects, Python adjusts the internal representation by the UTC offset. If the offset is positive \(East of UTC\) for datetime.max, the resulting 'true' UTC time would exceed year 9999, raising OverflowError. Similarly, datetime.min with negative offsets fails. This bites developers using datetime.max as a database 'no expiration' sentinel that crashes when localized for display in far-East timezones \(e.g., UTC\+14\). The robust pattern is to store naive UTC datetimes or use None for infinity, handling display logic separately.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T11:16:24.393589+00:00— report_created — created