-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[C++] compute::LocalTimestamp()
Performs incorrect conversion
#45751
Comments
compute::LocalTimestamp()
Resulting in incorrect conversioncompute::LocalTimestamp()
Performs incorrect conversion
Just to add, experimenting with a different timezone library (link) gets the expected 2222982812 value: #include <iostream>
#include <chrono>
#include <date/date.h>
#include <date/tz.h>
int main() {
date::sys_seconds utc_time{std::chrono::seconds(2222997212)};
date::zoned_time ny_time{"America/New_York", utc_time};
std::cout << "Epoch seconds: " << ny_time.get_sys_time().time_since_epoch().count() << std::endl;
std::cout << "UTC time: " << date::format("%F %T %Z", utc_time) << '\n';
std::cout << "NY time: " << date::format("%F %T %Z", ny_time) << '\n';
date::local_seconds naive_local = ny_time.get_local_time();
std::cout << "NY time naive: " << naive_local.time_since_epoch().count() << "\n";
} Output:
|
compute::LocalTimestamp()
Performs incorrect conversioncompute::LocalTimestamp()
Performs incorrect conversion
BTW, why do you want to get offset-ed seconds? FYI: The document of |
Hi @kou thank you for your time and reply,
Apologies I am confused, from the documentation I thought that was the exact purpose of the
At least the implication of that from the the way its written is that it is performing the following calculation (which is what I am looking for): I should also note for ~99% of cases I've tested so far the
I am trying to write a small CLI tool that converts parquet data to XPT format; XPT format however has no support for timezones so how to correctly store timestamp data is dependent on the use case; some users prefer to store the data as timezone-naive whilst others (myself included) prefer to just store the UTC-relative timestamps. To this end I am just providing an option for the user to choose. |
Describe the bug, including details regarding any error messages, version, and platform.
Apologies in advance if I've made a mistake here I am relatively new to the arrow Cpp API and also to managing datetime stamps, that being said I think there might be a bug with the
compute::LocalTimestamp()
function (at least it appears to be producing results I wouldn't have expected:For example take a timestamp(seconds) of
Assuming that the value was stored in a Timestamp array with a timezone of EDT I would have expected after running
compute::LocalTimestamp()
a value to be produced of:However in practice when doing this I am observing an actual value of:
I tried searching but I couldn't see any other issues (open or closed) related to this.
I am running on Fedora 41 using libarrow-16.1.0-12.fc41.x86_64 (latest available from the fedora package manager)
--- EDIT - Just tested against
arrow-19.0.1
and am still getting the same behavior ---Code I am running to reproduce this:
Component(s)
C++
The text was updated successfully, but these errors were encountered: