[
https://issues.apache.org/jira/browse/HIVE-21094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743180#comment-16743180
]
Karen Coppage commented on HIVE-21094:
--------------------------------------
Patch 1 doesn't work with Druid, and it was hacky anyway. The reason was
because both writing and reading TimestampTZs require converting a String to a
TimestampTz(Writable) back to a String, and I wasn't able to differentiate
between writing (when we want to convert to GMT) and reading (when we want to
convert to server time).
Since this fix doesn't really change behavior – it might change performance
based on the use case –, I'm putting this back on the shelf.
IMO either the inner representation of TimestampTZ should be Instant (not
ZonedDateTime), since it behaves like Instant; or a better solution will need
to be found.
> Store TIMESTAMP WITH LOCAL TIME ZONE in UTC instead of writer's time zone
> -------------------------------------------------------------------------
>
> Key: HIVE-21094
> URL: https://issues.apache.org/jira/browse/HIVE-21094
> Project: Hive
> Issue Type: Improvement
> Components: Hive
> Reporter: Karen Coppage
> Assignee: Karen Coppage
> Priority: Major
> Attachments: HIVE-21094.1.patch
>
>
> TIMESTAMP WITH LOCAL TIME ZONE (aka TIMESTAMPTZ) is stored in writer's local
> time, and the writer's zone is stored with it. When reading, the timestamp in
> reader local time + reader zone is displayed. This is misleading for the
> user, since it looks like all the data was written in the reader's time zone.
> TIMESTAMPTZ should be stored in UTC time and be displayed in reader local
> time (as it was before) but should not display the reader's time zone.
> This was discussed in the community doc [Consistent timestamp types in Hadoop
> SQL
> engines|https://docs.google.com/document/d/1gNRww9mZJcHvUDCXklzjFEQGpefsuR_akCDfWsdE35Q/edit?usp=sharing]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
