This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jamercee
Recipients jamercee
Date 2020-05-25.16:47:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1590425273.09.0.343345283384.issue40771@roundup.psfhosted.org>
In-reply-to
Content
We encountered an interesting mtime problem in the field, that I believe represents a bug in python's datetime timestamp handling.

A file stored on a windows server had the last-modified date '1/1/4501' (that's the year 4501). os.path.getmtime() returns a valid timestamp, but when we try to pass this back into datetime.datetime.fromtimestamp() we get an OSError.

I understand that generating an OSError when the date exceeds the epoch support on Windows is consistent with the python docs. In our case, the date is clearly supported by Windows as evidenced by it's storage in the filesystem. Further, we can reproduce the situation using the cygwin touch utility.

>>> import os, datetime
>>> os.system('touch -d "4501-01-01" file.txt')
>>> t = os.path.getmtime('file.txt')
>>> datetime.datetime.fromtimestamp(t)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

What's interesting is we can manually convert it with reference to the epoch

>>> datetime.datetime(1970, 1, 1) + datetime.timedelta(seconds=t)
datetime.datetime(4501, 1, 1, 5, 0)

We used Windows 10-Pro for our tests running python 3.8.1.
History
Date User Action Args
2020-05-25 16:47:53jamerceesetrecipients: + jamercee
2020-05-25 16:47:53jamerceesetmessageid: <1590425273.09.0.343345283384.issue40771@roundup.psfhosted.org>
2020-05-25 16:47:53jamerceelinkissue40771 messages
2020-05-25 16:47:52jamerceecreate