-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
[Go] Time to Date32 / Date64 conversion incorrect for non-UTC timezone #39672
Comments
zeroshade
added a commit
to zeroshade/arrow
that referenced
this issue
Jan 17, 2024
zeroshade
added a commit
that referenced
this issue
Jan 18, 2024
…mezones (#39674) A failing unit test in release verification led to discovering an issue with timestamp to date conversions for non-utc timezones. Upon some investigation I was able to determine that it was the conflation of casting conversion behavior (normalize to cast a Timestamp to a Date) vs flat conversion. I've fixed this conflation of concerns and the version of the methods which are exported properly converts non-UTC timezones to dates without affecting Casting behavior. ### Are these changes tested? yes ### Are there any user-facing changes? The methods `Date32FromTime` and `Date64FromTime` will properly handle timezones now. * Closes: #39672 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
clayburn
pushed a commit
to clayburn/arrow
that referenced
this issue
Jan 23, 2024
…UTC timezones (apache#39674) A failing unit test in release verification led to discovering an issue with timestamp to date conversions for non-utc timezones. Upon some investigation I was able to determine that it was the conflation of casting conversion behavior (normalize to cast a Timestamp to a Date) vs flat conversion. I've fixed this conflation of concerns and the version of the methods which are exported properly converts non-UTC timezones to dates without affecting Casting behavior. ### Are these changes tested? yes ### Are there any user-facing changes? The methods `Date32FromTime` and `Date64FromTime` will properly handle timezones now. * Closes: apache#39672 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
dgreiss
pushed a commit
to dgreiss/arrow
that referenced
this issue
Feb 19, 2024
…UTC timezones (apache#39674) A failing unit test in release verification led to discovering an issue with timestamp to date conversions for non-utc timezones. Upon some investigation I was able to determine that it was the conflation of casting conversion behavior (normalize to cast a Timestamp to a Date) vs flat conversion. I've fixed this conflation of concerns and the version of the methods which are exported properly converts non-UTC timezones to dates without affecting Casting behavior. ### Are these changes tested? yes ### Are there any user-facing changes? The methods `Date32FromTime` and `Date64FromTime` will properly handle timezones now. * Closes: apache#39672 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
raulcd
pushed a commit
that referenced
this issue
Feb 20, 2024
…mezones (#39674) A failing unit test in release verification led to discovering an issue with timestamp to date conversions for non-utc timezones. Upon some investigation I was able to determine that it was the conflation of casting conversion behavior (normalize to cast a Timestamp to a Date) vs flat conversion. I've fixed this conflation of concerns and the version of the methods which are exported properly converts non-UTC timezones to dates without affecting Casting behavior. ### Are these changes tested? yes ### Are there any user-facing changes? The methods `Date32FromTime` and `Date64FromTime` will properly handle timezones now. * Closes: #39672 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
zanmato1984
pushed a commit
to zanmato1984/arrow
that referenced
this issue
Feb 28, 2024
…UTC timezones (apache#39674) A failing unit test in release verification led to discovering an issue with timestamp to date conversions for non-utc timezones. Upon some investigation I was able to determine that it was the conflation of casting conversion behavior (normalize to cast a Timestamp to a Date) vs flat conversion. I've fixed this conflation of concerns and the version of the methods which are exported properly converts non-UTC timezones to dates without affecting Casting behavior. ### Are these changes tested? yes ### Are there any user-facing changes? The methods `Date32FromTime` and `Date64FromTime` will properly handle timezones now. * Closes: apache#39672 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
thisisnic
pushed a commit
to thisisnic/arrow
that referenced
this issue
Mar 8, 2024
…UTC timezones (apache#39674) A failing unit test in release verification led to discovering an issue with timestamp to date conversions for non-utc timezones. Upon some investigation I was able to determine that it was the conflation of casting conversion behavior (normalize to cast a Timestamp to a Date) vs flat conversion. I've fixed this conflation of concerns and the version of the methods which are exported properly converts non-UTC timezones to dates without affecting Casting behavior. ### Are these changes tested? yes ### Are there any user-facing changes? The methods `Date32FromTime` and `Date64FromTime` will properly handle timezones now. * Closes: apache#39672 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug, including details regarding any error messages, version, and platform.
During release verification, a unit test was failing with:
Component(s)
Go
The text was updated successfully, but these errors were encountered: