Message339038
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). |
|
Date |
User |
Action |
Args |
2019-03-28 13:41:47 | p-ganssle | set | recipients:
+ p-ganssle, vstinner, Tiger-222 |
2019-03-28 13:41:47 | p-ganssle | set | messageid: <1553780507.23.0.241501403379.issue36439@roundup.psfhosted.org> |
2019-03-28 13:41:47 | p-ganssle | link | issue36439 messages |
2019-03-28 13:41:47 | p-ganssle | create | |
|