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
The current implementation of toString for DuckDBTimestampTZValue doesn't include the timezone offset.
The main challenge is getting the appropriate timezone information to this method. Calculating the necessary timezone offset in hours and minutes is currently only possible by running a SQL expression (select timezone_hour(current_timestamp), timezone_minute(current_timestamp);). Since it's not reasonable to run SQL every time toString is called, this information should be gathered and stored somewhere else, perhaps in a global.
Most of the time, the user is likely to want to use whatever timezone the machine is set to. But, in some scenarios, the user may want to set a different timezone. Ensuring the global state that controls the timezone display is in sync with the DuckDB TimeZone setting could prove a challenge. But perhaps for this advanced use case it's okay to require an additional call from the user to update the global state for the updated timezone setting.
The text was updated successfully, but these errors were encountered:
The current implementation of
toString
forDuckDBTimestampTZValue
doesn't include the timezone offset.The main challenge is getting the appropriate timezone information to this method. Calculating the necessary timezone offset in hours and minutes is currently only possible by running a SQL expression (
select timezone_hour(current_timestamp), timezone_minute(current_timestamp);
). Since it's not reasonable to run SQL every timetoString
is called, this information should be gathered and stored somewhere else, perhaps in a global.Most of the time, the user is likely to want to use whatever timezone the machine is set to. But, in some scenarios, the user may want to set a different timezone. Ensuring the global state that controls the timezone display is in sync with the DuckDB TimeZone setting could prove a challenge. But perhaps for this advanced use case it's okay to require an additional call from the user to update the global state for the updated timezone setting.
The text was updated successfully, but these errors were encountered: