[
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16530350#comment-16530350
]
Julian Hyde commented on CALCITE-2394:
--------------------------------------
By the way. We have not considered how the TIMESTAMP WITH LOCAL TIME ZONE type
should be handled in Avatica, but clearly the right thing is not perform
timezone translation. For instance, you should be able to call
PreparedStatement.setObject with an Instant, then later call
ResultSet.getObject(int, Instant.class).
> 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)
