[
https://issues.apache.org/jira/browse/CALCITE-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147950#comment-16147950
]
Julian Hyde commented on CALCITE-1947:
--------------------------------------
I'm still really confused by the semantics of this.
One solution is to rename class TimestampWithLocalTimeZoneString to
TimestampWithTimeZoneString. Because you have implemented a literal for
TIMESTAMP WITH TIME ZONE. It's confusing to pretend otherwise.
Now, if you need to know the time zone during simplification, that's fine, but
put that time zone in the simplifier, not the literal.
I know you're trying to produce something that models Hive's semantics. I find
Hive's semantics confusing, but my understanding was that they were just like
java.util.Date: an instant, whose value is stored relative to epoch UTC, and
which does not contain a time zone (albeit it uses JVM's time zone if you are
foolish enough to call java.util.Date.toString). We ran with that concept, and
we needed a name for the SQL type, and we decided to go with TIMESTAMP WITH
LOCAL TIME ZONE.
Maybe the name of that SQL type is confusing, and people expect there to be a
time zone stored inside it. If that's the case, let's find a better name for
the SQL type.
> 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)
