[
https://issues.apache.org/jira/browse/CALCITE-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624043#comment-14624043
]
Lukas Lalinsky commented on CALCITE-796:
----------------------------------------
I don't believe JSON has any strictly defined limits on integer sizes, so
serializing it into a 96 bit integer would be fine. The reason I suggested the
decimal number is because that way clients could send just the integer part,
which could be defined as UNIX timestamp and the fractional part could be
optional. But that's probably slightly biased point of view, because that's how
timestamps typically work in Python.
> Avatica remote service truncates java.sql.Timestamp truncates to milliseconds
> -----------------------------------------------------------------------------
>
> Key: CALCITE-796
> URL: https://issues.apache.org/jira/browse/CALCITE-796
> Project: Calcite
> Issue Type: Bug
> Reporter: Lukas Lalinsky
> Assignee: Julian Hyde
>
> TypedValue in Avatica read/writes java.sql.Timestamp even though natively the
> type supports nanosecond precision (and Phoenix does use the full precision).
> The JSON serialization protocol should count with this.
> I'd suggest serializing java.sql.Timestamp with `toString()` and
> deserializing with `valueOf()` if it's a string. Alternatively, it could be
> stored as a decimal number or just total number of nanoseconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
