[jira] [Resolved] (CALCITE-7494) Avatica conversion to string of TIMESTAMP WITH TIME ZONE does not include time zone

["Mihai Budiu (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-7494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mihai Budiu resolved CALCITE-7494.
----------------------------------
    Fix Version/s: avatica-1.29
         Assignee: Mihai Budiu
       Resolution: Fixed

Fixed in [https://github.com/apache/calcite-avatica/commit/3e48dffb68b527c84b062e2d3c0c6b24ab5f0321]

Thank you for the review [~jensen]

> Avatica conversion to string of TIMESTAMP WITH TIME ZONE does not include time zone
> -----------------------------------------------------------------------------------
>
>                 Key: CALCITE-7494
>                 URL: https://issues.apache.org/jira/browse/CALCITE-7494
>             Project: Calcite
>          Issue Type: Bug
>          Components: avatica
>    Affects Versions: avatica-1.27.0
>            Reporter: Mihai Budiu
>            Assignee: Mihai Budiu
>            Priority: Minor
>              Labels: pull-request-available
>             Fix For: avatica-1.29
>
>
> Here is the output of a quidem test from CALCITE-7491 (after fixing the issue):
> {code:java}
>  select TIMESTAMP WITH TIME ZONE '2020-01-01 00:00:00 America/New_York';
> +---------------------+
> | EXPR$0              |
> +---------------------+
> | 2020-01-01 05:00:00 |
> +---------------------+{code}
> Note that the timestamp does not include time zone information.
> There are two mainstream representations of runtime values of TIMESTAMP WITH TIME ZONE: most databases just normalize them to UTC timezones and discard the timezone information. A couple of databases preserve the time zone as well. This is an important distinction, because it affects when two such timestamps are equal.
> I am proposing to implement the simpler definition. 
> A second question is about the string representation of such a timestamp. Postgres converts it into the session timezone. An alternative would be to always display it in the UTC timezone. The latter approach has the nice property that it's deterministic for writing tests.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)