You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org> on 2018/07/03 16:38:00 UTC

[jira] [Updated] (HIVE-20073) Additional tests for to_utc_timestamp function based on HIVE-20068

     [ https://issues.apache.org/jira/browse/HIVE-20073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesus Camacho Rodriguez updated HIVE-20073:
-------------------------------------------
    Status: Patch Available  (was: In Progress)

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