[
https://issues.apache.org/jira/browse/CALCITE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17585675#comment-17585675
]
Julian Hyde commented on CALCITE-5250:
--------------------------------------
You might be right, but let me add a few data points:
* This code is probably dealing with java.sql.Date, which is a sub-class of
java.util.Date but overrides some important methods
* That subclass, DateFromNumberAccessor, assumes that the column on the server
side is a SQL DATE, not a TIMESTAMP
* Avatica by default represents a SQL DATE value as a Java int (32 bits
signed), number of DAYS in the Julian calendar since 1970-01-01; it represents
a SQL TIMESTAMP as a Java long (64 bits signed), number of MILLISECONDS since
1970-01-01 00:00:00.
If you're seeing values going over the wire that look like milliseconds, it's
possible that the server has a TIMESTAMP (possibly you call it a DATETIME since
you're in the Googleverse) but the client is expecting days.
> Possible bug in date conversion
> -------------------------------
>
> Key: CALCITE-5250
> URL: https://issues.apache.org/jira/browse/CALCITE-5250
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Affects Versions: 1.22.0
> Reporter: Will Noble
> Assignee: Will Noble
> Priority: Minor
>
> In
> [DateFromNumberAccessor.getDate()|https://github.com/apache/calcite-avatica/blob/d88f91a3ed8590ab8cee0df5c53633b3d5e41c59/core/src/main/java/org/apache/calcite/avatica/util/AbstractCursor.java#L929]
> we multiply the number by {{{}MILLIS_PER_DAY{}}}. However, I'm observing
> that the integer values being sent over the wire (using the JsonHandler) are
> already expressed in milliseconds since epoch, as seen in
> [DateSerializer._timestamp()|https://github.com/FasterXML/jackson-databind/blob/b688919010a9147376dc435f742812afd5b46885/src/main/java/com/fasterxml/jackson/databind/ser/std/DateSerializer.java#L41]
> in jackson-databind (java.util.date.getTime returns time in milliseconds).
> So, the returned dates are super far in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
