[jira] [Comment Edited] (CALCITE-1947) Add time/timestamp with local time zone types to optimizer

["Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146263#comment-16146263 ] 

Jesus Camacho Rodriguez edited comment on CALCITE-1947 at 8/29/17 10:35 PM:
----------------------------------------------------------------------------

Thanks for the feedback [~julianhyde].

{quote}
We are on shaky ground if the literal has more information content than the runtime value.
{quote}

Statically we have information about the timezone that we can use to perform some optimizations, e.g., constant reduction. I decided to include that information within the value because I was facing issues to retrieve the timezone information when doing optimizations on RexNode, since all the related utilities are executed without context information. Basically what I am doing is passing that context information when I am creating the RexNode value, rather than passing context information to code that should be context independent (except for this bit). Do you have another idea on how to architect this part?

{quote}
Also, if I create TimestampWithLocalTimeZoneString("1970-01-01 08:00:00", "PST") and TimestampWithLocalTimeZoneString("1970-01-01 05:00:00", "EST") these values are equal, and have identical values in their internal fields. Their value is the epoch - either 0L or "1970-01-01 00:00:00", I don't care how you represent it internally.
{quote}
I agree, I will change the {{compareTo}} method to normalize both values to UTC, that would be give the correct behavior.


was (Author: jcamachorodriguez):
{quote}
We are on shaky ground if the literal has more information content than the runtime value.
{quote}
Thanks for the feedback [~julianhyde].

Statically we have information about the timezone that we can use to perform some optimizations, e.g., constant reduction. I decided to include that information within the value because I was facing issues to retrieve the timezone information when doing optimizations on RexNode, since all the related utilities are executed without context information. Basically what I am doing is passing that context information when I am creating the RexNode value, rather than passing context information to code that should be context independent (except for this bit). Do you have another idea on how to architect this part?

{quote}
Also, if I create TimestampWithLocalTimeZoneString("1970-01-01 08:00:00", "PST") and TimestampWithLocalTimeZoneString("1970-01-01 05:00:00", "EST") these values are equal, and have identical values in their internal fields. Their value is the epoch - either 0L or "1970-01-01 00:00:00", I don't care how you represent it internally.
{quote}
I agree, I will change the {{compareTo}} method to normalize both values to UTC, that would be give the correct behavior.

> Add time/timestamp with local time zone types to optimizer
> ----------------------------------------------------------
>
>                 Key: CALCITE-1947
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1947
>             Project: Calcite
>          Issue Type: New Feature
>          Components: core
>            Reporter: Jesus Camacho Rodriguez
>            Assignee: Jesus Camacho Rodriguez
>             Fix For: 1.14.0
>
>
> Implementation would be similar to PostgreSQL (the {{time/timestamp with timezone}} types do not store the timezone) and conversion from/to timezone-less types follows similar semantics.
> https://www.postgresql.org/docs/9.6/static/functions-datetime.html
> This would also allow us to integrate easily with Hive and Druid, which follow similar storage models/semantics for timestamp with timezone.
> Follow-up work will be needed to introduce these new types in Avatica and extend Calcite SQL parser.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)