[ https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17345559#comment-17345559 ]
Kenneth Knowles commented on CALCITE-2394: ------------------------------------------ Unassigning to be realistic about the fact that I am not working on this and will not have time to do so. > 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 > 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 (v8.3.4#803005)