On twitter, someone asked about a weird difference in the error messages from datetime.fromtimestamp() when called with a timestamp that falls on 10000-01-01 when compared to 10000-01-02. Compare:
$ TZ=UTC python -c "from datetime import *; datetime.fromtimestamp(253402300799 + 1)"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ValueError: year 0 is out of range
$ TZ=UTC python -c "from datetime import *; datetime.fromtimestamp(253402300799 + 1 + 24 * 3600)"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ValueError: year 10000 is out of range
Turns out that this is because in the localtime-specific implementation of datetime.fromtimestamp in _datetimemodule.c, there's an unchecked error condition when calling utc_to_seconds, which fails with -1.
As a practical matter, this always results in basically the same error anyway, since in all situations where result_seconds gets set to -1 the subsequent calculations fail anyway, and the only difference is that the error message has a slightly different form, but we may as well fix this.
On twitter, someone asked about a weird difference in the error messages from
datetime.fromtimestamp()when called with a timestamp that falls on 10000-01-01 when compared to 10000-01-02. Compare:Turns out that this is because in the localtime-specific implementation of
datetime.fromtimestampin_datetimemodule.c, there's an unchecked error condition when callingutc_to_seconds, which fails with-1.As a practical matter, this always results in basically the same error anyway, since in all situations where
result_secondsgets set to-1the subsequent calculations fail anyway, and the only difference is that the error message has a slightly different form, but we may as well fix this.