[
https://issues.apache.org/jira/browse/CALCITE-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634089#comment-14634089
]
Julian Hyde commented on CALCITE-797:
-------------------------------------
I have re-opened the issue since there seems more to discuss.
[~lukaslalinsky], I agree it makes sense to send the full java.sql.Time value
(i.e. in prepare). But I think the values returned (i.e. in fetch) should be
SQL TIME values, with no date part.
Although this is asymmetric, it is consistent with the JDBC API: the types of
parameters are determined by the client (whatever type of Java object the
client chooses to supply) whereas the types of columns in a result set are
determined by the server.
> Avatica remote service strips the date part from java.sql.Time
> --------------------------------------------------------------
>
> Key: CALCITE-797
> URL: https://issues.apache.org/jira/browse/CALCITE-797
> Project: Calcite
> Issue Type: Bug
> Reporter: Lukas Lalinsky
> Assignee: Julian Hyde
>
> java.sql.Time is basically an UNIX timestamp with both date and time. The
> documentation says the date part should not be used, but Phoenix does use it.
> While it is possible to pass the full timestamp as a parameter value, the
> client will only get time part back.
> Given that using the date part is deprecated according to the documentation,
> I'm not sure if you want to support this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
