[
https://issues.apache.org/jira/browse/CALCITE-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145998#comment-16145998
]
Julian Hyde commented on CALCITE-1947:
--------------------------------------
The information content of a TIMESTAMP WITH LOCAL TIME ZONE value is just a 64
bit integer, no time zone. So it doesn't seem right that the
TimeWithLocalTimeZoneString has a time zone inside it. We are on shaky ground
if the literal has more information content than the runtime value.
This change adds a new data type, and we ought to nail down the semantics,
which would include tests of various queries and also tests for JDBC driver
support. I think it is unreasonable for me to expect all of that, but the time
zone field in TimeWithLocalTimeZoneString needs to go, otherwise we will be
tempted to give this the same semantics as TIMESTAMP WITH TIME ZONE, which it
emphatically does not.
Can you also update reference.md with the new data types.
In Hive (and the semantics I assume you are trying to achieve here), is the
time zone offset applied when the query is parsed, or when it is executed? I
would assume parse time. If so, if I, in PST, parse a query with {{TIMESTAMP
WITH LOCAL TIME ZONE '1970-01-01 08:00:00'}}, I would expect it to create a
TimestampWithLocalTimeZone(0L).
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.
> 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)
