Skip to content

feat: Add from_datetime method to Timestamp types#9345

Open
codephage2020 wants to merge 13 commits intoapache:mainfrom
codephage2020:issue-9337
Open

feat: Add from_datetime method to Timestamp types#9345
codephage2020 wants to merge 13 commits intoapache:mainfrom
codephage2020:issue-9337

Conversation

@codephage2020
Copy link
Contributor

Which issue does this PR close?

Closes #9337

Rationale for this change

What changes are included in this PR?

Are these changes tested?

YES

Are there any user-facing changes?

YES, Now it is possible to directly convert from datatime to timestamp.

before:
DateTime<Tz> → .naive_local() /.naive_utc() → NaiveDateTime → make_value() → i64
now:
DateTime<Tz> → i64 (timestamp)

@github-actions github-actions bot added the arrow Changes to the arrow crate label Feb 3, 2026
1. Introduce from_datetime<Tz: TimeZone> and a from_naive_datetime default to the ArrowTimestampType trait to provide a unified, timezone-aware way to create timestamp values. Implement these methods for all Timestamp* types .
2. Update and refactor tests to exercise UTC and FixedOffset conversions, subsecond precision, and naive-datetime-to-timezone roundtrips.
Copy link
Contributor

@sdf-jkl sdf-jkl left a comment

Choose a reason for hiding this comment

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

Everything LGTM, but one comment below

@codephage2020 codephage2020 requested a review from sdf-jkl February 6, 2026 05:38
@codephage2020
Copy link
Contributor Author

@sdf-jkl Thank you for your review.
Added tests for LocalResult edge cases:

timestamp_from_naive_datetime_ambiguous - tests DST end transition (returns first match)
timestamp_from_naive_datetime_none - tests DST start transition with non-existent time (returns None)

CC @alamb

Copy link
Contributor

@sdf-jkl sdf-jkl left a comment

Choose a reason for hiding this comment

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

Nice, everything LGTM

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thanks @codephage2020 and @sdf-jkl -- this looks great to me, except for one question (on returning Option). Let me know what you think

}

fn from_datetime<Tz: TimeZone>(datetime: DateTime<Tz>) -> i64 {
datetime.timestamp_nanos_opt().expect("timestamp overflow")
Copy link
Contributor

Choose a reason for hiding this comment

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

🤔 this panic is unfortunate. Perhaps we should change the signature to return Option to avoid this?

/// # Arguments
///
/// * `naive` - The local datetime to convert
/// * `tz` - Optional timezone. If `None`, interprets as UTC.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you also add a note here that that passing None is the same as calling Self::make_value?

And while we are considering this, I think it it would be worth deprecating make_value entirely and suggesting everyone uses from_naive_datetime (as a follow on PR, not in this one). Thoughts?

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

Labels

arrow Changes to the arrow crate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add some way to create a Timestamp from a DateTime

3 participants