You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have "iso" and "local" derivations for temporal types, but these are probably not doing exactly what they should do.
For DuckDB temporal types that do not support a time zone, one can debate what the correct interpretation should be:
Should they be interpreted as absolute (UTC)?
Should they be interpreted as being in some timezone chosen by the user?
Maybe some other item in the dataset suggests what the timezone should be? It could be that the timezone is in a separate column, or it could be that there is country/region information that should be used as the locality, determining the tz.
For the ones that have an explicit timezone, it is at least absolutely clear what the time is.
In these cases, one could desire to see the value in the user's local time
The text was updated successfully, but these errors were encountered:
We currently have "iso" and "local" derivations for temporal types, but these are probably not doing exactly what they should do.
For DuckDB temporal types that do not support a time zone, one can debate what the correct interpretation should be:
For the ones that have an explicit timezone, it is at least absolutely clear what the time is.
In these cases, one could desire to see the value in the user's local time
The text was updated successfully, but these errors were encountered: