gh-81708: Support negative timestamps in _PyTime_localtime for windows #131056
Conversation
|
On the overall approach, I guess it fills in a gap, but I'd prefer to have a single codepath that handles it all. Dates/times are hard though, and I'm not even going to pretend I know how this function is actually meant to behave. My preference would be to use the best available OS API for the entire job, rather than splitting it up. If no such API exists, something like this I'd think we could implement ourselves and stop relying on the OS entirely. But if the people who understand this particular subject better than me say it's not safe to make a change like that, then I'm happy enough to go with their recommendation. I'm not sure who those people are right now. |
Switching |
2 participants
DO NOT MERGE.
This is a work-in-progress/proof-of-concept pull request for not using
localtimeon Windows for negative epoch values but instead using win32 APIs. We basically have a set of long-standing issues and work-arounds/platform specific code for the fact thatlocaltimeon Windows does not support negative numbers, unlike our other platforms.Some examples from a quick search include:
datetime.fromtimestamp(t).astimezone()fails for0<=t<86400in Windows #107078The changes to
Python/pytime.care the ones to look at, the rest are just enabling tests/removing work-arounds. Note that I had to use anif-guard to only use the new win32 apis when the unix timestamp is>= 0because as it turns out,mktimeon Windows has this behavior where it just doesn't account for DST correctly. Without it, tests that rely on round-trippingmktimeandlocaltimefail. (See this repo for more details on that)There is also the question on how to support
tm_ydayandtm_isdst. I have an implementation oftm_ydayand a commented out one fortm_isdst./cc @zooba for thoughts on this approach, whether it's worth pursuing.
/cc @eryksun for Windows expertise on the APIs/methodology