Repository navigation
datetime.fromtimestamp(t).astimezone() fails for 0<=t<86400 in Windows #107078
Description
Bug report
dt.datetime.fromtimestamp(t).astimezone() fails for 0<=t<86400 in Windows for at least python 3.9, 3.10, 3.11.
Works fine in Linux, Mac.
>> import datetime as dt
>> dt.datetime.fromtimestamp(0)
datetime.datetime(1970, 1, 1, 1, 0)
>> dt.datetime.fromtimestamp(86400)
datetime.datetime(1970, 1, 2, 1, 0)
>> dt.datetime.fromtimestamp(0).astimezone()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument
>> dt.datetime.fromtimestamp(86399).astimezone()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument
>> dt.datetime.fromtimestamp(86400).astimezone()
datetime.datetime(1970, 1, 2, 1, 0, tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'W. Europe Standard Time'))A screenshot also:
Your environment
- CPython versions tested on: 3.9, 3.10, 3.11
- Operating system and architecture: Windows
Additional information
This looks very very related to this issue: #73283 but now it seems to happen for astimezone.
Activity
littlebutt commentedon Jul 23, 2023
I think the bug was introduced by
_datetimemodule.chere.cpython/Modules/_datetimemodule.c
Line 6336 in 7fc9be3
If the
tis not large enough, thelocalmethod will return -1 since it will minus an epoch time(62135683200).pythongh-107078: fix `astimezone` on Windows
Merge branch 'main' into pythongh-107078
littlebutt commentedon Jul 24, 2023
The thing is that if the
tyou passed is so small, the internal parameteru2will be negative. Since the methodlocaltime_scannot accept a negative parameter, it will throw an OSError. I just plused amax_fold_secondsto make sure theu2is positive. I admit it is not an elegant solotion.Merge branch 'main' into pythongh-107078
Fix (Paraswap): python/cpython/issues/107078
Fix (Paraswap): python/cpython/issues/107078
Fix (Paraswap): python/cpython/issues/107078
Fix (Paraswap): python/cpython/issues/107078
Fix (Paraswap): python/cpython/issues/107078
serhiy-storchaka commentedon Feb 1, 2024
On Linux timestamp can be negative. Why the interval 0-86400 is so important that it is worth to support it on Windows, but not negative timestamps? It is just a limitation of the platform.
zooba commentedon Feb 1, 2024
I suspect the value
0is important, as it's an obvious edge case (or null case). Investigating that revealed that the first value that works is86400, and so that's the range.I guess people are less surprised that
-1doesn't work? TBH, I'd be okay with making this calculation fully Python specific, rather than trying to use OS APIs, assuming we can find a migration path. The CRT emulation clearly isn't compatible enough, and the OS APIs are so much richer that they aren't really compatible either.There was some discussion about adopting ICU for this kind of stuff... maybe if we ever do that we can have consistent timezone handling?
leon-adarcewicz commentedon Nov 25, 2024
Hi folks,
I fail with same issue for
datetime.datetime(1900, 1, 1, 9, 0).astimezone(tz=None)==>[Errno 22] Invalid argument,so I wanted to check if the is some solution for this issue for windows users?
wkoot commentedon Oct 28, 2025
Is this not a duplicate of #80620 ?
sigma67 commentedon Nov 26, 2025
It does seem to fail for every date before 1970 as well.
vstinner commentedon Jan 15, 2026
Issue fixed by #143463.
ndonkoHenri commentedon Jan 16, 2026
@vstinner thanks for the info! Is there any chance we have that fix in some other "older" python versions (3.13, 3.14, for example) too? If yes, when can we expect them to land in an official release?
vstinner commentedon Jan 16, 2026
Hi. The change is a new feature, not a bugfix, so it cannot be backported. It will only be part of Python 3.15 and newer.