Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32k
gh-130718: Normalize edge cases indatetime.timestamp
anddatetime.astimezone
#130752
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.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I don't really understand why this is working even to the extent that is currently working. IIUC,local
is supposed to return something like the number of seconds since 1970-01-01T00:00in local time (assuming that local time is an idealized calendar), but now we have a situation where in the failure cases, it just returns whatever the input was, and none of the callers have been updated to understand this. Why is the
local` call required at all?
I suspect that this is not the right way to handle this. I don't fully understand what's going on here, but I think we either need to relax the validation inutc_to_seconds
to allow forintermediate values to fall outsideMIN_YEAR
/MAX_YEAR
, or we need to find a way to do these same calculations that doesn't involve calculating these UTC seconds at all (or, if that's much slower than what we're doing now, try the current method and fall back to the slower method if we fall outside the boundaries during the intermediate values).
Uh oh!
There was an error while loading.Please reload this page.
@@ -3122,6 +3122,18 @@ def dst(self, dt): return 1 | |||
with self.assertRaises(TypeError): | |||
dt_broken.astimezone() | |||
dt_big = self.theclass(9999, 12, 31, 23, 59, 59) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I don't love that the original style violates the one-assert-per-test style, and we should probably not continue that.
Let's move this into its own method, liketest_astimezone_max
andtest_astimezone_min
. We can test the values neardatetime.min
anddatetime.max
separately, and useself.subTest
to try a few different values for time zone.
I'm not sure if@support.run_with_tz
can be parameterized, but if it can we should try it on a few different time zones.
@@ -5424,7 +5425,14 @@ local(long long u) | |||
} | |||
if (_PyTime_localtime(t, &local_time) != 0) | |||
return -1; | |||
return utc_to_seconds(local_time.tm_year + 1900, | |||
// Check edge cases |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This should be more specific — what this code does is very opaque, so we should have a "why" comment here. Something like "When the year is outside the allowed year boundaries, return the original utc timestamp because ".
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 |
Uh oh!
There was an error while loading.Please reload this page.
For cases with minimal values, the error still raising but now it is different, it is caught in a different place and I think for this we should to open a separate issue.
I'm also not sure if this change needs a news entry because it's the expected behavior:
New behavior:
Old behavior:
datetime.astimezone
method #130718