-
Notifications
You must be signed in to change notification settings - Fork 242
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
[FEA] Support parsing dates and timestamps with timezone IDs in the string #6846
Open
3 tasks
Tracked by
#2063
Labels
feature request
New feature or request
Comments
revans2
added
feature request
New feature or request
? - Needs Triage
Need team to review and classify
labels
Oct 18, 2022
47 tasks
revans2
added
the
reliability
Features to improve reliability or bugs that severly impact the reliability of the plugin
label
Aug 16, 2023
Alfred is co-working on this. |
To note: It's probably more relevant to support offsets in the string as opposed to full timezone IDs. Offsets are part of the toString output of OffsetDateTime in Java, and the ISO 8601 format (using the 'Z'). The ISO 8601 format is common enough that it should be the priority of support in this feature. |
mattahrens
removed
the
reliability
Features to improve reliability or bugs that severly impact the reliability of the plugin
label
Jan 3, 2024
I'm not planing work on this for release 24.04 |
34 tasks
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Is your feature request related to a problem? Please describe.
When parsing CSV or JSON, and when casting from a string to a timestamp or a date it is allowed to have a timezone id in the string itself. Ideally we should be able to support this. It might take some custom kernel work to do it. But if we can have the names of all of the time zones cached on the GPU along with the offset tables similar to what is described in #6831 and #6840 then we could detect zones that are UTC+/- and GMT +/- along with the actual named zones. (There are also aliases for UTC/etc that we will need a way to express too). But with that, then the parsing code can look up the corresponding timezone and adjust the result appropriately when parsing the data. This is likely going to need more custom kernels to make this fully work.
The text was updated successfully, but these errors were encountered: