[
https://issues.apache.org/jira/browse/HIVE-20073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533910#comment-16533910
]
Hive QA commented on HIVE-20073:
--------------------------------
Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12930319/HIVE-20073.01.patch
{color:green}SUCCESS:{color} +1 due to 1 test(s) being added or modified.
{color:green}SUCCESS:{color} +1 due to 14639 tests passed
Test results:
https://builds.apache.org/job/PreCommit-HIVE-Build/12405/testReport
Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/12405/console
Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-12405/
Messages:
{noformat}
Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.YetusPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
{noformat}
This message is automatically generated.
ATTACHMENT ID: 12930319 - PreCommit-HIVE-Build
> 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: HIVE-20073.01.patch, HIVE-20073.patch,
> 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)