Skip to content

BUG: construct Timestamp with year out of pydatetime range #52191

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

jbrockmendel
Copy link
Member

f"Cannot construct a Timestamp with year={year} and "
"non-zero nanoseconds"
)
return obj.as_unit("us").replace(year=year)
Copy link
Member

Choose a reason for hiding this comment

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

What if the year goes beyond the us max year but within the ms max year?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. And same for seconds.

Now you've got me thinking about value-dependent behavior. We should probably get "us" unit whenever nanos is zero-or-None regardless of year. Same for getting "ms" if micros is (zero % 1000)-or-None, etc

@mroeschke mroeschke added Non-Nano datetime64/timedelta64 with non-nanosecond resolution Timestamp pd.Timestamp and associated methods labels Mar 27, 2023
@github-actions
Copy link
Contributor

This pull request is stale because it has been open for thirty days with no activity. Please update and respond to this comment if you're still interested in working on this.

@github-actions github-actions bot added the Stale label Apr 27, 2023
@mroeschke
Copy link
Member

Closing to clear the queue, but feel free to reopen if you want to continue

@mroeschke mroeschke closed this Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Non-Nano datetime64/timedelta64 with non-nanosecond resolution Stale Timestamp pd.Timestamp and associated methods
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG or as expected/designed?: Generating and calculation with timestamps out of bound?
2 participants