Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

gh-130718: Normalize edge cases in datetime.timestamp and datetime.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.

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

Jump to bottom
Open
wants to merge 5 commits into
base: main
Choose a base branch
Loading
from
Open

gh-130718: Normalize edge cases in datetime.timestamp and datetime.astimezone #130752

wants to merge 5 commits into from
+26 −2

Conversation

donBarbos
Copy link
Contributor

@donBarbos donBarbos commented Mar 2, 2025 •
edited
Loading

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:

>>> from datetime import datetime
>>> datetime(9999, 12, 31).astimezone() # ok
datetime.datetime(9999, 12, 31, 0, 0, tzinfo=datetime.timezone(datetime.timedelta(seconds=14400), '+04'))
>>> datetime(9999, 12, 31).timestamp() # ok
253402200000.0
>>> datetime(9999, 12, 31, 23, 59, 59).astimezone() # ok
datetime.datetime(9999, 12, 31, 23, 59, 59, tzinfo=datetime.timezone(datetime.timedelta(seconds=14400), '+04'))
>>> datetime(9999, 12, 31, 23, 59, 59).timestamp() # ok
253402286399.0

Old behavior:

>>> from datetime import datetime
>>> datetime(9999, 12, 31).astimezone() # not ok
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    datetime(9999, 12, 31).astimezone()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
ValueError: year must be in 1..9999, not 10000
>>> datetime(9999, 12, 31, 20).timestamp() # not ok
Traceback (most recent call last):
  File "<python-input-5>", line 1, in <module>
    datetime(9999, 12, 31, 20).timestamp()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
ValueError: year must be in 1..9999, not 10000

@bedevere-app bedevere-app bot mentioned this pull request Mar 2, 2025
Open
pganssle
pganssle requested changes May 19, 2025
View reviewed changes
Copy link
Member

@pganssle pganssle left a 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 thelocal` 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 in utc_to_seconds to allow for intermediate values to fall outside MIN_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).

Modules/_datetimemodule.c Show resolved Hide resolved
Lib/test/datetimetester.py
@@ -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)
Copy link
Member

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, like test_astimezone_max and test_astimezone_min. We can test the values near datetime.min and datetime.max separately, and use self.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.

Modules/_datetimemodule.c
@@ -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
Copy link
Member

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 ".

@bedevere-app
Copy link

bedevere-app bot commented May 19, 2025

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 have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pganssle pganssle pganssle requested changes

@abalkin abalkin Awaiting requested review from abalkin abalkin is a code owner

Assignees
No one assigned
Labels
awaiting changes
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@donBarbos @pganssle
Morty Proxy This is a proxified and sanitized view of the page, visit original site.