[
https://issues.apache.org/jira/browse/CALCITE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597372#comment-17597372
]
Julian Hyde commented on CALCITE-5250:
--------------------------------------
I don't totally recall how this works, but I'm a bit surprised to see Jackson
serializing a Date object. We avoid Date objects on the server side because:
* It's too easy to confuse java.util.Date with java.sql.Time,
java.sql.Timestamp, java.sql.Date;
* Date objects take quite a bit of time to construct;
* Each Date object is (in Joda parlance) an Instant (i.e. implicitly in UTC)
whereas a SQL DATE value is (in Joda parlance) a DateTime (i.e. in no time
zone) and it's too easy to get confused.
Therefore I think that your server should be producing Integer values.
If that's the case I apologize that Avatica didn't warn you.
> 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)
