Skip to content

gh-107078: fix astimezone on Windows #107176

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
littlebutt wants to merge 4 commits into from
+10 −0
Closed

gh-107078: fix astimezone on Windows #107176

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
623902d
gh-107078: fix `astimezone` on Windows
littlebutt Jul 24, 2023
fa97af3
📜🤖 Added by blurb_it.
blurb-it[bot] Jul 24, 2023
841392f
Merge branch 'main' into gh-107078
littlebutt Jul 24, 2023
66525da
Merge branch 'main' into gh-107078
littlebutt Jul 24, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions Misc/NEWS.d/next/Windows/2023-07-24-13-35-22.gh-issue-107078.leZSPg.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Fix `_datetimemodule.c` when calling `datetime.datetime.fromtimestamp(0).astimezone()` with `OSError` on Windows
9 changes: 9 additions & 0 deletions Modules/_datetimemodule.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6333,9 +6333,18 @@ local_to_seconds(int year, int month, int day,
u2 = u1 + max_fold_seconds;
else
u2 = u1 - max_fold_seconds;
#ifdef MS_WINDOWS
u2 += max_fold_seconds;
Copy link
Member

@zooba zooba Jan 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@serhiy-storchaka serhiy-storchaka Feb 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @zooba. See the Windows-specific comment in datetime_from_timet_and_us().

Also this change needs tests.

#endif

lt = local(u2);
if (lt == -1)
return -1;
#ifdef MS_WINDOWS
u2 -= max_fold_seconds;
lt -= max_fold_seconds;
#endif

b = lt - u2;
if (a == b)
return u1;
Expand Down