[
https://issues.apache.org/jira/browse/HIVE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520636#comment-16520636
]
Haozhun Jin commented on HIVE-12192:
------------------------------------
[~jcamachorodriguez], I notice that there have been a lot of activities on this
issue recently. Thank you for pushing this forward.
I have a few questions.
1. Is the following understanding correct and reflect current state of
HIVE-12192?
||Hive Type||Legacy Hive||Before HIVE-16614--||After HIVE-16614--||After
HIVE-12192||Eventually||
|Timestamp|Instant (for computation)
LocalDateTime (for storage)|Instant (for computation)
LocalDateTime (for storage)|Instant (for computation)
LocalDateTime (for storage)|LocalDateTime|LocalDateTime|
|Timestamp w local tz|(not present)|(not present)|Instant|Instant|Instant|
|Timestamp w tz|(not present)|Instant|(not present)|(not present)|ZonedDateTime|
(for computation) the behavior that one can observe by running a query (by
applying functions and/or operators on value of timestamp type)
(for storage) the behavior that one can observe by first writing data using an
environment in one zone, and then reading the data out from an environment in a
different zone.
2. Is there any current plans beyond HIVE-12192? (Specifically, will there be a
"timestamp w tz" soon?)
3. Is there any planned changes to DATE semantics? Had there been any changes
to DATE semantics?
> Hive should carry out timestamp computations in UTC
> ---------------------------------------------------
>
> Key: HIVE-12192
> URL: https://issues.apache.org/jira/browse/HIVE-12192
> Project: Hive
> Issue Type: Sub-task
> Components: Hive
> Reporter: Ryan Blue
> Assignee: Jesus Camacho Rodriguez
> Priority: Blocker
> Labels: timestamp
> Fix For: 3.1.0
>
> Attachments: HIVE-12192.01.patch, HIVE-12192.02.patch,
> HIVE-12192.03.patch, HIVE-12192.04.patch, HIVE-12192.05.patch,
> HIVE-12192.06.patch, HIVE-12192.07.patch, HIVE-12192.08.patch,
> HIVE-12192.09.patch, HIVE-12192.10.patch, HIVE-12192.11.patch,
> HIVE-12192.12.patch, HIVE-12192.13.patch, HIVE-12192.14.patch,
> HIVE-12192.15.patch, HIVE-12192.16.patch, HIVE-12192.17.patch,
> HIVE-12192.18.patch, HIVE-12192.19.patch, HIVE-12192.20.patch,
> HIVE-12192.patch
>
>
> Hive currently uses the "local" time of a java.sql.Timestamp to represent the
> SQL data type TIMESTAMP WITHOUT TIME ZONE. The purpose is to be able to use
> {{Timestamp#getYear()}} and similar methods to implement SQL functions like
> {{year}}.
> When the SQL session's time zone is a DST zone, such as America/Los_Angeles
> that alternates between PST and PDT, there are times that cannot be
> represented because the effective zone skips them.
> {code}
> hive> select TIMESTAMP '2015-03-08 02:10:00.101';
> 2015-03-08 03:10:00.101
> {code}
> Using UTC instead of the SQL session time zone as the underlying zone for a
> java.sql.Timestamp avoids this bug, while still returning correct values for
> {{getYear}} etc. Using UTC as the convenience representation (timestamp
> without time zone has no real zone) would make timestamp calculations more
> consistent and avoid similar problems in the future.
> Notably, this would break the {{unix_timestamp}} UDF that specifies the
> result is with respect to ["the default timezone and default
> locale"|https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-DateFunctions].
> That function would need to be updated to use the
> {{System.getProperty("user.timezone")}} zone.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
