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
To correctly implement time(z)/timestamp(z) we must leverage the SQL-session zone offset. This is outside the scope of current Datum work which is to simply use java.time as the backing classes. I've created this issue to document the intentional behavioral gap to reduce PR scope.
Additional Context
For the convenience of users, whenever a datetime value with time zone is to be implicitly derived from one without (for example, in a simple assignment operation), SQL assumes the value without time zone to be local, subtracts the default SQL-session time zone displacement from it to give UTC, and associates that time zone displacement with the result.
Conversely, whenever a datetime value without time zone is to be implicitly derived from one with, SQL assumes the value with time zone to be UTC, adds the time zone displacement to it to give local time, and the result, without any time zone displacement, is local.
p.26
The text was updated successfully, but these errors were encountered:
Description
To correctly implement time(z)/timestamp(z) we must leverage the SQL-session zone offset. This is outside the scope of current Datum work which is to simply use java.time as the backing classes. I've created this issue to document the intentional behavioral gap to reduce PR scope.
Additional Context
p.26
The text was updated successfully, but these errors were encountered: