[ https://issues.apache.org/jira/browse/HIVE-20073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on HIVE-20073 started by Jesus Camacho Rodriguez. ------------------------------------------------------ > 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 > Assignee: Jesus Camacho Rodriguez > Priority: Minor > 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)