[ https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16530382#comment-16530382 ]
Julian Hyde commented on CALCITE-2394: -------------------------------------- Per [Rows.java|https://github.com/julianhyde/sqlline/blob/b14152adc0c8df2554334df57724b034fc5f77b1/src/main/java/sqlline/Rows.java#L194], SQLline seems to be calling ResultSet.getString() if it is a TIMESTAMP value. That seems to be the right thing to do. As long as a the driver isn't trying to convert the SQL TIMESTAMP into a java.sql.Timestamp and/or apply timezone translation before converting to string. > Avatica applies calendar offset to timestamps when they should remain > unchanged > ------------------------------------------------------------------------------- > > Key: CALCITE-2394 > URL: https://issues.apache.org/jira/browse/CALCITE-2394 > Project: Calcite > Issue Type: Bug > Components: avatica > Reporter: Kenneth Knowles > Assignee: Kenneth Knowles > Priority: Major > > This code converts a millis-since-epoch value to a timestamp in three > different accessors: > {code} > class AbstractCursor { > ... > static Timestamp longToTimestamp(long v, Calendar calendar) { > if (calendar != null) { > v -= calendar.getTimeZone().getOffset(v); > } > return new Timestamp(v); > } > } > {code} > But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT. > The use in {{DateFromNumberAccessor}} is probably OK: it fabricates > millis-since-epoch from a date, so applying the offset is appropriate to hit > midnight in that locale. > But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} > should leave the millis absolute. > This manifests as timestamp actual values being shifted by the current locale > (in addition to later display adjustments). -- This message was sent by Atlassian JIRA (v7.6.3#76005)