[ 
https://issues.apache.org/jira/browse/CALCITE-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430936#comment-16430936
 ] 

Julian Hyde commented on CALCITE-2243:
--------------------------------------

I see. So you could probably hard-code {{private static final Long NOW = 
1234567L;}} (i.e. no dependence on the wall-clock) and see similar behavior. It 
seems to be about time-zones, and the timezone-offset conversion that happens 
when you convert a SQL timestamp value (represented as a 64-bit signed long) to 
a {{java.sql.Timestamp}} value via {{ResultSet.getObject()}}. I think Avatica 
will send back the first N rows, and if N = 100 that would explain why the 
behavior changes. The problem (and fix) may be in Avatica.

I don't have time to debug this but hopefully I've given someone clues where to 
look.

> Timestamp values change with remote connection when the result set size 
> exceeds 100 rows
> ----------------------------------------------------------------------------------------
>
>                 Key: CALCITE-2243
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2243
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.16.0
>            Reporter: Markku Vuorenmaa
>            Assignee: Julian Hyde
>            Priority: Major
>         Attachments: TimestampsIssue.java
>
>
> Table queries with TIMESTAMP values return incorrect values when the result 
> set size is larger than 100 rows. Perhaps the timezone shift is calculated 
> twice, as the first 100 lines are correct and the bug always occurs after 
> that. The default fetch size in the code seems to be 100. The bug should be 
> reproducable by running the attached code, which the same model with local 
> and remote connection and gets a different data as a result.
> Some output shortly:
> Local:
> {{#1 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#2 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#100 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#101 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#102 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#200 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> Remote:
> {{#1 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#2 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#100 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#101 TIME=2018-04-09 08:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#102 TIME=2018-04-09 08:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#200 TIME=2018-04-09 08:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{[^TimestampsIssue.java]}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to