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
Support fetching TIMESTAMPTZ as SQL_TYPE_TIMESTAMP
DuckDB supports `TIMESTAMP WITH TIME ZONE` data type that stores UTC
dates (with specified time zone already applied on DB insert). ODBC
does not have a notion of time zones. When client app reads such
`TIMESTAMP WITH TIME ZONE` it needs to be converted into
`TIMESTAMP WITHOUT TIME ZONE` with client-local time zone applied. And
such converted timestamp must represent the same moment of time as
stored UTC timestamp.
Applying client-local time zone to timestamp is a non-trivial operation
- the UTC offset depends on both the time zone (for fixed shift) and on
the timestamp value (for DST shift).
There are two options to get the effective offset for the specified UTC
timestamp in the specified time zone:
- DuckDB ICU extension, that will use DB-configured time zone
- OS API, will use OS-configured time zone
Variant with ICU extension appeared to be problematic, as we would like
to not link neither to ICU extension (C++ API, not in DuckDB C API) nor
to ICU itself (C API exists, but symbols include ICU major version that
can change). We can do ICU call from ODBC by creating SQL string and
executing it. But this conversion must be performed for every value in
every row. And there no reasonbly-easy ways to cache the results. Thus
the idea of SQL calls was rejected.
Variant with OS API matches the approach used in JDBC (see
duckdb/duckdb-java#166) where JVM-configured time zone is used
(invariant 1 there).
The problem with accessing OS API is that `<ctime>` utilities are not
thread-safe until `C++20`. Thus Windows `<timezoneapi.h>` and POSIX
`<time.h>` API are used directly. And `<ctime>` approach is used in
tests for cross-checking.
Testing: new test added that fetches `TIMESTAMP WITH TIME ZONE` value
as `SQL_C_TYPE_TIMESTAMP` and checks that it is shifted correctly.
0 commit comments