[ 
https://issues.apache.org/jira/browse/HIVE-20068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531655#comment-16531655
 ] 

Jesus Camacho Rodriguez commented on HIVE-20068:
------------------------------------------------

This is solved in Hive 3.1 and Hive 4.0 via HIVE-12192 and HIVE-20007, 
respectively.

I have created a clone HIVE-20073 to push the example in the description as a 
test to master and branch-3. I will leave this one open in case someone wants 
to tackle issue in 2.x line.

> 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
>         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)

Reply via email to