[
https://issues.apache.org/jira/browse/CALCITE-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678869#comment-17678869
]
Julian Hyde commented on CALCITE-5487:
--------------------------------------
Is string the right representation? If {{TIMESTAMP}} is represented as a Java
{{long}} (64 bit signed integer) (I am making assumptions here - I haven't
checked the code) then I think {{TIMESTAMP WITH LOCAL TIME ZONE}} could perhaps
also be represented as a {{long}}.
The case is different from {{TIMESTAMP WITH TIME ZONE}}, which definitely
requires more than 64 bits of information.
> Avatica Result Sets do not properly handle TIMESTAMP WITH LOCAL TIME ZONE
> -------------------------------------------------------------------------
>
> Key: CALCITE-5487
> URL: https://issues.apache.org/jira/browse/CALCITE-5487
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Reporter: Will Noble
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With the addition of proper support for {{TIMESTAMP WITH LOCAL TIME ZONE}} to
> Calcite being done as part of CALCITE-5346, Avatica needs to support the
> proper semantics for this type. Whereas a regular {{TIMESTAMP}} always has
> the same string representation but can have different instants depending on
> the calendar (time zone) passed to the result set getter, a {{TIMESTAMP WITH
> LOCAL TIME ZONE}} does the inverse: it always represents the same instant,
> but could have a different string representation depending on the calendar
> passed to the result set getter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
