[issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0

[Paul Ganssle]

Paul Ganssle <p.ganssle at gmail.com> added the comment:

>From the documentation ( https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp ):

> fromtimestamp() may raise OverflowError, if the timestamp is out of the range
> of values supported by the platform C localtime() or gmtime() functions, and
> OSError on localtime() or gmtime() failure. It’s common for this to be
> restricted to years in 1970 through 2038. Note that on non-POSIX systems that
> include leap seconds in their notion of a timestamp, leap seconds are ignored
> by fromtimestamp(), and then it’s possible to have two timestamps differing by
> a second that yield identical datetime objects. See also utcfromtimestamp().

So this is indeed the documented behavior. I agree that it would be good to unify the behavior across platforms if possible, but I think this would require us to have our own implementation of localtime() and/or gmtime().

That said, it might be possible to implement `fromtimestamp` with some equivalent of `datetime(1970, 1, 1) + timedelta(seconds=t)` on Windows when the value falls outside the accepted range. We'd probably need some better tests under different time zones to make sure that that would be acceptable.

I think it may be a good idea to change the targeted version to 3.8 or 3.9, because this is a change to the documented behavior of the function (albeit a desirable one that can probably be considered backwards compatible).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________