You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Kenneth Knowles (JIRA)" <ji...@apache.org> on 2018/07/02 15:38:00 UTC

[jira] [Created] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

Kenneth Knowles created CALCITE-2394:
----------------------------------------

             Summary: 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


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)