gh-107078: fix astimezone on Windows#107176
Conversation
|
Hello! Bumping the PR in case someone can take a look |
| else | ||
| u2 = u1 - max_fold_seconds; | ||
| #ifdef MS_WINDOWS | ||
| u2 += max_fold_seconds; |
There was a problem hiding this comment.
I think we only want to do this if it's too small? Otherwise it has the potential to do the conversion wrong if you put in a "normal" time that's within max_fold_seconds of an offset change (either DST or legal change). We probably assume that none of these happened on the first day after epoch.
Otherwise, this seems like a fine way to handle it. A "real" fix would be much more complex, and probably inconsistent with actual timezone aware datetimes, which I'm sure are the preferred approach these days.
There was a problem hiding this comment.
I agree with @zooba. See the Windows-specific comment in datetime_from_timet_and_us().
Also this change needs tests.
| else | ||
| u2 = u1 - max_fold_seconds; | ||
| #ifdef MS_WINDOWS | ||
| u2 += max_fold_seconds; |
There was a problem hiding this comment.
I agree with @zooba. See the Windows-specific comment in datetime_from_timet_and_us().
Also this change needs tests.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
I merged #143463 instead. Thanks for your contribution anyway ;-) |
6 participants
_datetimemodule.cwhen callingdatetime.datetime.fromtimestamp(0).astimezone()withOSErroron Windowsdatetime.fromtimestamp(t).astimezone()fails for0<=t<86400in Windows #107078