We encountered an interesting mtime problem we encountered in the field. I'm planning to file a bug report, but wanted to get outside perspective.
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
.
There are several discussions on SO that talk around this issue, for example: Python fromtimestamp OSError. However, in most of the cases we could find, the OP were dealing with manufactured dates that clearly were outside the platform's supported epoch range. 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.