[
https://issues.apache.org/jira/browse/HIVE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522843#comment-16522843
]
Jesus Camacho Rodriguez commented on HIVE-12192:
------------------------------------------------
[~findepi], [~haozhun], yes, got lost between all these ptest runs, sorry about
that.
1. Yes, that table seems to summarize current status and roadmap. {{After
HIVE-12192}} would mean after 3.1.0.
2. We would like to have timestamp with tz too. However, adding a new type
requires some work and there is no timeline right now.
3. Date can be considered to follow similar evolution as Timestamp: internal
representation will be as LocalDate after 3.1.0. The change is part of this
patch.
bq. Note, since other products cannot be made dependent on single Hive version,
it's critical to understand semantics differences introduced by this issue, if
any.
The expectation is that from user perspective, date and timestamp should be
compliant with SQL semantics. In addition, different timezones will not result
in any unexpected results from now on.
> 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.21.patch, HIVE-12192.22.patch, HIVE-12192.23.patch,
> HIVE-12192.24.patch, HIVE-12192.25.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)
