You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/07/02 16:58:00 UTC
[jira] [Commented] (CALCITE-2394) Avatica applies calendar offset
to timestamps when they should remain unchanged
[ https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16530178#comment-16530178 ]
ASF GitHub Bot commented on CALCITE-2394:
-----------------------------------------
GitHub user kennknowles opened a pull request:
https://github.com/apache/calcite-avatica/pull/63
[CALCITE-2394] Fix TIMESTAMP accessors: test with non-default, non-zero timezone
This removes some millis-since-epoch arithmetic from the accessor for a timestamp. In fact, no arithmetic should be necessary for absolute instant references on the data plane, but only during pretty printing. The issue manifests as timestamp columns always being off for any non-zero timezone locale.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kennknowles/calcite-avatica timestamp
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/calcite-avatica/pull/63.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #63
----
commit 9f6e246e3b9d952341eff37650fa866c31952292
Author: Kenneth Knowles <kl...@...>
Date: 2018-07-02T16:10:43Z
Fix TIMESTAMP accessors: test with non-default, non-zero timezone
----
> 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)