datetime.fromtimestamp(t).astimezone() fails for 0<=t<86400 in Windows

[LefterisJP]

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.

Linked PRs

• gh-107078: fix astimezone on Windows #107176

[littlebutt]

I think the bug was introduced by _datetimemodule.c here.

cpython/Modules/_datetimemodule.c

Line 6336 in 7fc9be3

lt = local(u2);

If the t is not large enough, the local method will return -1 since it will minus an epoch time(62135683200).

[littlebutt]

The thing is that if the t you passed is so small, the internal parameter u2 will be negative. Since the method localtime_s cannot accept a negative parameter, it will throw an OSError. I just plused a max_fold_seconds to make sure the u2 is positive. I admit it is not an elegant solotion.

[serhiy-storchaka]

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]

I suspect the value 0 is important, as it's an obvious edge case (or null case). Investigating that revealed that the first value that works is 86400, and so that's the range.

I guess people are less surprised that -1 doesn'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?