[
https://issues.apache.org/jira/browse/HIVE-20068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez updated HIVE-20068:
-------------------------------------------
Affects Version/s: 2.4.0
2.1.1
> Potential Issue with to_utc_timestamp Function with US/Eastern Constant
> -----------------------------------------------------------------------
>
> Key: HIVE-20068
> URL: https://issues.apache.org/jira/browse/HIVE-20068
> Project: Hive
> Issue Type: Bug
> Affects Versions: 2.1.1, 2.4.0
> Environment: MapR running on Linux I believe. Client is DBeaver on
> Windows 7.
> Reporter: JAMES J STEINBUGL
> 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)
