You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
datetime.timestamp() fails before 1970-01-02T01:00:00.000000 #94414
Cannot reproduce this on Arch with python 3.10.5 with the system clock set to UTC+1. Perhaps this only affects Windows. Are you able to reproduce this using python 3.10?
C:\>py -3.10
Python 3.10.5 (tags/v3.10.5:f377153, Jun 6 2022, 16:14:13) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime, timezone
>>> datetime(1970,1,1,0,0,0, tzinfo=None).timestamp()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument
>>> datetime(1970,1,1,0,0,0, tzinfo=timezone.utc).timestamp()
0.0
>>> import time
>>> time.tzname
('Romance Standard Time', 'Romance Daylight Time')
>>>
This should come from the fact that without any timezone specified, the lib relies on the Windows function which does not support times before the Epoch. The strange thing is that the whole day after the Epoch is unusable, which cannot be explained only by time zone.
While running property-based tests with Hypothesis, I discovered that datetime.timestamp() also fails with the same error on Windows 10 x64 for datetimes after datetime.datetime(3001, 1, 19, 7, 59, 59, 999999).
This issue is present on Windows 10 for Python 9, Python10 and Python11, and on Windows 11 for Python 11. I did not tested it on Python 9 and Python 10 on Windows 11.
In addition to the timestamp() function, a similar error is raised with the astimezone() function. For example, the following code fail with an OSError: [Errno 22] Invalid argument error:
@picnixz Maybe you could clean this up (since you seem to like triaging ;-) and decide which one should stay (at least please do add the os-windows labels, this project really needs some triaging :-( and unfortunately there is no way for most people to help with that) ?
Activity
dtyeos commentedon Jun 29, 2022
Probable duplicate of gh-817081
Footnotes
@erlend-aasland: edited the BPO link to a GitHub Issues link, for the convenience of the reader ↩dtyeos commentedon Jun 29, 2022
dignissimus commentedon Jun 29, 2022
Cannot reproduce this on Arch with python 3.10.5 with the system clock set to UTC+1. Perhaps this only affects Windows. Are you able to reproduce this using python 3.10?
dtyeos commentedon Jun 30, 2022
This should come from the fact that without any timezone specified, the lib relies on the Windows function which does not support times before the Epoch. The strange thing is that the whole day after the Epoch is unusable, which cannot be explained only by time zone.
benpryke commentedon Mar 21, 2023
While running property-based tests with Hypothesis, I discovered that
datetime.timestamp()also fails with the same error on Windows 10 x64 for datetimes afterdatetime.datetime(3001, 1, 19, 7, 59, 59, 999999).Specifically:
I suspect this is related to the max value of the argument to
time.ctimeon Windows 10 x64 as discussed in this Stack Overflow thread.achoum commentedon Mar 21, 2024
This issue is present on Windows 10 for Python 9, Python10 and Python11, and on Windows 11 for Python 11. I did not tested it on Python 9 and Python 10 on Windows 11.
In addition to the
timestamp()function, a similar error is raised with theastimezone()function. For example, the following code fail with anOSError: [Errno 22] Invalid argumenterror:Note: This issue is likely related to #81708
ItsPadar commentedon Dec 5, 2024
This issue is present on Python 3.12.7 on Windows 10 32bit and is causing me issues between production and development enviroments
StanFromIreland commentedon Mar 9, 2025
Duplicates: #94757, #81708
StanFromIreland commentedon Mar 13, 2025
@picnixz Maybe you could clean this up (since you seem to like triaging ;-) and decide which one should stay (at least please do add the os-windows labels, this project really needs some triaging :-( and unfortunately there is no way for most people to help with that) ?
They are all because we use localtime_s
picnixz commentedon Mar 30, 2025
I'll close this one as a duplicate of #81708 (as this is about being close to the EPOCH in some sense).