-
Notifications
You must be signed in to change notification settings - Fork 875
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
Fix timestamp handling in cast kernel (#1936) (#4033) #4034
Conversation
/// Creates a ArrowTimestampType::Native from the provided [`NaiveDateTime`] | ||
/// | ||
/// See [`DataType::Timestamp`] for more information on timezone handling | ||
fn make_value(naive: NaiveDateTime) -> Option<i64>; |
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 is the fix for #4033
let array = array.as_string::<O>(); | ||
let out: PrimitiveArray<T> = match to_tz { | ||
Some(tz) => { | ||
let tz: Tz = tz.as_ref().parse()?; |
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 is the fix for #1936
"2022-12-31 20:35:06".to_string(), | ||
] | ||
); | ||
// Non-absolute timestamps should be parsed preserving the same local instant |
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.
More background on this can be found in #1936, in particular #1936 (comment)
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.
Makes sense to me. Cc @waitingkuo @avantgardnerio and @doki23
Thank you @tustvold |
Which issue does this PR close?
Closes #1936
Closes #4033
Rationale for this change
What changes are included in this PR?
Are there any user-facing changes?
This is technically a breaking change to functionality added in #3673 by @comphead, I'm inclined to think this is ok.