You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by "Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org> on 2018/07/03 16:38:00 UTC
[jira] [Created] (HIVE-20073) Additional tests for to_utc_timestamp
function based on HIVE-20068
Jesus Camacho Rodriguez created HIVE-20073:
----------------------------------------------
Summary: Additional tests for to_utc_timestamp function based on HIVE-20068
Key: HIVE-20073
URL: https://issues.apache.org/jira/browse/HIVE-20073
Project: Hive
Issue Type: Bug
Environment: MapR running on Linux I believe. Client is DBeaver on Windows 7.
Reporter: JAMES J STEINBUGL
Attachments: image-2018-07-03-08-50-42-390.png
I have the following script and I'm at loss to explain the behavior. Possibly it's an older bug as we are using the 2.1.1 drivers (?). We noticed this issue when converting from US/Eastern into UTC and then back to US/Eastern. Everything that was in Status Date / Status Hour on 3/11/17 21:00:00 shifted 6 hours ahead into UTC ... then shifted back to 3/11/17 22:00:00 back in US/Eastern. The behavior appears to be the same using the constant EST5EDT. EDT was effective on 3/12 2 am, so the issue appears only at this boundary condition when we "spring ahead", but it at least on the surface seems incorrect.
--------------------------------------------------------------------------------------------------------------------------
-- Potential Issue with to_utc_timestamp
---------------------------------------------------------------------------------------------------------------------------
SELECT '2017-03-11 18:00:00', to_utc_timestamp(timestamp '2017-03-11 18:00:00','US/Eastern'); -- Shifts ahead 5 hours as expected
SELECT '2017-03-11 19:00:00', to_utc_timestamp(timestamp '2017-03-11 19:00:00','US/Eastern'); -- Shifts ahead 5 hours as expected
SELECT '2017-03-11 20:00:00', to_utc_timestamp(timestamp '2017-03-11 20:00:00','US/Eastern'); -- Shifts ahead 5 hours as expected
{color:#FF0000}SELECT '2017-03-11 21:00:00', to_utc_timestamp(timestamp '2017-03-11 21:00:00','US/Eastern'); -- Shifts ahead 6 hours (???){color}
{color:#FF0000}_c0 _c1
2017-03-11 21:00:00 2017-03-12 03:00:00{color}
SELECT '2017-03-11 22:00:00', to_utc_timestamp(timestamp '2017-03-11 22:00:00','US/Eastern'); -- Shifts ahead 5 hours as expected
SELECT '2017-03-11 23:00:00', to_utc_timestamp(timestamp '2017-03-11 23:00:00','US/Eastern'); -- Shifts ahead 5 hours as expected
SELECT '2017-03-12 00:00:00', to_utc_timestamp(timestamp '2017-03-12 00:00:00','US/Eastern'); -- Shifts ahead 5 hours as expected
SELECT '2017-03-12 01:00:00', to_utc_timestamp(timestamp '2017-03-12 01:00:00','US/Eastern'); -- Shifts ahead 5 hours as expected
SELECT '2017-03-12 02:00:00', to_utc_timestamp(timestamp '2017-03-12 02:00:00','US/Eastern'); -- Shifts ahead 5 hours as expected
SELECT '2017-03-12 03:00:00', to_utc_timestamp(timestamp '2017-03-12 03:00:00','US/Eastern'); -- Shifts ahead 4 hours as expected
SELECT '2017-03-12 04:00:00', to_utc_timestamp(timestamp '2017-03-12 04:00:00','US/Eastern'); -- Shifts ahead 4 hours as expected
SELECT '2017-03-12 05:00:00', to_utc_timestamp(timestamp '2017-03-12 05:00:00','US/Eastern'); -- Shifts ahead 4 hours as expected
!image-2018-07-03-08-50-42-390.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)