[
https://issues.apache.org/jira/browse/CALCITE-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146263#comment-16146263
]
Jesus Camacho Rodriguez commented on CALCITE-1947:
--------------------------------------------------
{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)
