[
https://issues.apache.org/jira/browse/CALCITE-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148244#comment-16148244
]
Jesus Camacho Rodriguez commented on CALCITE-1947:
--------------------------------------------------
As we discussed previously, the semantics of "timestamp with local time zone"
type is not only similar to Hive semantics, but also to Postgres "timestamp
with time zone" type and Oracle "timestamp with local time zone". It is indeed
an instant, but that instant is interpreted in the local time zone (which is
not necessarily the JVM time zone but rather the property value for the local
time zone).
{quote}
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.
{quote}
That sounds good to me. In fact, we do indeed call the Hive literal timestamp
with time zone. We could use the same literal to store both "timestamp with
local time zone" and "timestamp with time zone" when we have an implementation
in the future.
I have pushed a new commit to the PR that I think will address your concerns:
it represents internally the time/timestamp with local time zone types as
TimeString/TimestampString, and then relies on the logic in
TimeWithTimeZone/TimestampWithTimeZoneString when it needs to make any
transformation. Initially I thought that doing that would be more elaborated,
but then I realized I had all the information I needed when we need to do the
interpretation of the literal, e.g., for constant reduction. Please, let me
know what you think. Thanks!
> 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)
