[
https://issues.apache.org/jira/browse/CALCITE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697667#comment-17697667
]
Julian Hyde commented on CALCITE-5552:
--------------------------------------
I agree. CALCITE-5488 is related. My hunch is that we should do this first, and
then attack 5488 with what we learn from that fix. We need to answer the
fundamental question "Do I need to run an Avatica server in UTC time zone? If
not, what should be its behavior?"
> Returned timestamp is incorrect after the 100th row
> ---------------------------------------------------
>
> Key: CALCITE-5552
> URL: https://issues.apache.org/jira/browse/CALCITE-5552
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Affects Versions: avatica-1.23.0
> Reporter: Magnus Mogren
> Priority: Critical
> Attachments: TSTAMPS.csv
>
>
> When fetching data that contains timestamps the returned timestamp after row
> 100 is incorrect.
> This can be reproduced using the CSV adapter (calcite-csv) using the
> TSTAMPS.csv file attached. It contains 101 timestamps with the value
> 1900-01-01 00:00:00. The first 100 is returned correctly, but number 101 in
> the result has the value 1899-12-31 23:00:00 instead.
> Marking this bug as critical since not beeing able to trust the values
> returned by calcite is as bad as it gets in my opinion.
> I do not know if the bug is in calcite or avatica.
> I have created a project that reproduces the issue. You can find that here:
> [nytro77/calcite-timestamp-bug: Showcase bug in Calcite or Avatica that
> causes faulty timestamps to be returned
> (github.com)|https://github.com/nytro77/calcite-timestamp-bug]
> It starts an AvaticaServer that serves the attached file as a table using
> calcite-csv and a unit tests that connects to the server and fetches the data.
> Run it withÂ
> {code:java}
> ./mvnw test{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
