[
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17627304#comment-17627304
]
Ian Bertolacci commented on CALCITE-2394:
-----------------------------------------
Is this related to, or the cause of, CALCITE-4120?
> 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.20.10#820010)
