Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
3.1.2
-
None
-
None
Description
Timestamp values falling into the daylight savings time of the system timezone cannot be retrieved as is when those are stored in Parquet/Avro tables. The respective SELECT query shifts those timestamps by +1 reflecting the DST shift.
Example
--! qt:timezone:US/Pacific create table employee (eid int, birthdate timestamp) stored as parquet; insert into employee values (0, '2019-03-10 02:00:00'); insert into employee values (1, '2020-03-08 02:00:00'); insert into employee values (2, '2021-03-14 02:00:00'); select eid, birthdate from employee order by eid;
Actual results
0 | 2019-03-10 03:00:00 |
1 | 2020-03-08 03:00:00 |
2 | 2021-03-14 03:00:00 |
Expected results
0 | 2019-03-10 02:00:00 |
1 | 2020-03-08 02:00:00 |
2 | 2021-03-14 02:00:00 |
Storing and retrieving values in columns using the timestamp data type (equivalent with LocalDateTime java API) should not alter at any way the value that the user is seeing. The results are correct for TEXTFILE and ORC tables.
Attachments
Attachments
Issue Links
- is caused by
-
HIVE-21290 Restore historical way of handling timestamps in Parquet while keeping the new semantics at the same time
- Closed
- relates to
-
HIVE-12192 Hive should carry out timestamp computations in UTC
- Closed
-
HIVE-20007 Hive should carry out timestamp computations in UTC
- Closed