Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
Support TIMESTAMP WITH LOCAL TIME ZONE type in JDBC driver.
Currently, Calcite types with SqlTypeName.TIMESTAMP_WITH_LOCAL_TIME_ZONE are mapped to JDBC type 1111 (OTHER). As a result, the ResultSet.toString() method just converts the (signed) long value to a string.
Here is what Progress says:
The Oracle TIMESTAMP WITH LOCAL TIME ZONE data type is mapped to the JDBC TIMESTAMP data type.
When retrieving TIMESTAMP WITH LOCAL TIME ZONE columns, the value returned to the user is converted to the time zone specified by the TIME_ZONE session parameter.
When setting TIMESTAMP WITH LOCAL TIME ZONE columns:
- Using a timestamp (using PreparedStatement.setTimestamp, for example), the value set is converted to the time zone specified by the TIME_ZONE session parameter.
- Using a string (using PreparedStatement.setString(), for example), the string is passed as-is to the server. The supplied string must be in the format specified by the NLS_TIMESTAMP_TZ_FORMAT session parameter. If not, the Oracle server generates an error when it attempts to convert the string to the TIMESTAMP WITH LOCAL TIME ZONE type.
We should definitely map to java.sql.Types.TIMESTAMP.
I'm not sure whether Calcite has a TIME_ZONE session parameter. But values should be shifted from/to the desired time zone on the way in/out.
And maybe there should also be a Calcite server time zone that is the time zone in which TIMESTAMP WITH LOCAL TIME ZONE values are represented. By default this should be UTC, and using a time zone with a variable offset from UTC (e.g. "Pacific/Los_Angeles") would be a bad idea.
Attachments
Issue Links
- is duplicated by
-
CALCITE-5500 Add support in Avatica for TIMESTAMP WITH LOCAL TIME ZONE
-
- Resolved
-
- is related to
-
CALCITE-5424 Customize handling of literals based on type system
-
- Closed
-
- relates to
-
CALCITE-5508 Add constructor functions for DATE, TIME, TIMESTAMP, DATETIME
-
- Closed
-
- links to