Zoltan Ivanfi created HIVE-21350:
------------------------------------
Summary: TIMESTAMP WITH LOCAL TIME ZONE
Key: HIVE-21350
URL: https://issues.apache.org/jira/browse/HIVE-21350
Project: Hive
Issue Type: Task
Reporter: Zoltan Ivanfi
As specified in the [design doc for TIMESTAMP
types|https://cwiki.apache.org/confluence/display/Hive/Different+TIMESTAMP+types],
the TIMESTAMP WITH LOCAL TIME ZONE type shall behave like the
[Instant|https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html]
class of Java, i.e., each value identifies a single time instant, but does not
contain any explicit timezone information. To achieve this semantics, the
processing of timestamp literals involves an implicit normalization from the
session-local time zone to a predefined one (typically but not necessarily
UTC), while displaying the stored timestamps involves an implicit conversion
from the predefined time zone to the session-local one. Although a predefined
time zone (typically UTC) was explicitly mentioned above, it is not a part of
the individual values but of the definition of the whole type instead. As such,
every value that gets stored has to be normalized to this predefined time zone
and therefore its original time zone information gets lost.
For example, if the calendar and clock hanging on the wall shows 1969-07-20
16:17:39 according to Eastern Daylight Time, that must be stored as "1969-07-20
20:17:39", because that UTC time corresponds to the same instant. When reading
that value back, we no longer know that it originated from an EDT time and we
can only display it in some fixed time zone (either local or UTC or specified
by the user).
This behaviour is consistent with some major DB engines, which is the best we
can do as no type is defined by the SQL standard that would have this behaviour.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
