[
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16530293#comment-16530293
]
Kenneth Knowles commented on CALCITE-2394:
------------------------------------------
I think there is a step prior to SQL or JDBC. Ignoring relativity, a moment in
time has no time zone, platonically.
What I'd like to know, then, is how to correctly store such a thing
(millisecond precision suffices for now) and retrieve it using Calcite Avatica.
> 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)
