[ https://issues.apache.org/jira/browse/HIVE-20007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16525992#comment-16525992 ]
Hive QA commented on HIVE-20007: -------------------------------- Here are the results of testing the latest attachment: https://issues.apache.org/jira/secure/attachment/12929350/HIVE-20007.patch {color:green}SUCCESS:{color} +1 due to 80 test(s) being added or modified. {color:green}SUCCESS:{color} +1 due to 14616 tests passed Test results: https://builds.apache.org/job/PreCommit-HIVE-Build/12205/testReport Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/12205/console Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-12205/ 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: 12929350 - PreCommit-HIVE-Build > Hive should carry out timestamp computations in UTC > --------------------------------------------------- > > Key: HIVE-20007 > URL: https://issues.apache.org/jira/browse/HIVE-20007 > Project: Hive > Issue Type: Sub-task > Components: Hive > Reporter: Ryan Blue > Assignee: Jesus Camacho Rodriguez > Priority: Blocker > Labels: timestamp > Attachments: HIVE-20007.patch > > > Hive currently uses the "local" time of a java.sql.Timestamp to represent the > SQL data type TIMESTAMP WITHOUT TIME ZONE. The purpose is to be able to use > {{Timestamp#getYear()}} and similar methods to implement SQL functions like > {{year}}. > When the SQL session's time zone is a DST zone, such as America/Los_Angeles > that alternates between PST and PDT, there are times that cannot be > represented because the effective zone skips them. > {code} > hive> select TIMESTAMP '2015-03-08 02:10:00.101'; > 2015-03-08 03:10:00.101 > {code} > Using UTC instead of the SQL session time zone as the underlying zone for a > java.sql.Timestamp avoids this bug, while still returning correct values for > {{getYear}} etc. Using UTC as the convenience representation (timestamp > without time zone has no real zone) would make timestamp calculations more > consistent and avoid similar problems in the future. > Notably, this would break the {{unix_timestamp}} UDF that specifies the > result is with respect to ["the default timezone and default > locale"|https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-DateFunctions]. > That function would need to be updated to use the > {{System.getProperty("user.timezone")}} zone. -- This message was sent by Atlassian JIRA (v7.6.3#76005)