[ https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16912895#comment-16912895 ]
Kenneth Knowles commented on CALCITE-2394: ------------------------------------------ FWIW here I've recently realized that Beam SQL is probably backwards. We have been mapping an absolute Joda-style instant to the Calcite type TIMESTAMP which is pretty explicitly wrong. We probably need to decide between `TIMESTAMP WITH TIMEZONE` to make it an absolute time (with extraneous metadata) versus `TIMESTAMP WITH LOCAL TIMEZONE` which to be honest I don't really understand. > 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 (v8.3.2#803003)