You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by "Richard Nadeau (JIRA)" <ji...@apache.org> on 2012/09/28 16:59:08 UTC
[jira] [Updated] (HIVE-3510) to_utc_timestamp() does not properly
handle UNIX timestamp conversions without nanoseconds
[ https://issues.apache.org/jira/browse/HIVE-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Nadeau updated HIVE-3510:
---------------------------------
Description:
When attempting to convert a UNIX timestamp to UTC the conversion fails if the input does not include micro or nano seconds:
{code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss'),'America/Denver') FROM source_table LIMIT 1;{code}
*1970-01-16 14:39:21.215*
"Converting" to a float provides a workaround:
{code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss') * 1.0,'America/Denver') FROM source_table LIMIT 1;{code}
*2012-09-27 15:53:35.0*
As does "adding" nano seconds:
{code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss') * 1000,'America/Denver') FROM source_table LIMIT 1;{code}
*2012-09-27 15:53:35.0*
This problem may be at the heart of HIVE-3454 as well.
Documentation here: https://cwiki.apache.org/Hive/languagemanual-types.html#LanguageManualTypes-Timestamps
was:
When attempting to convert a UNIX timestamp to UTC the conversion fails if the input does not include micro or nano seconds:
{code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss'),'America/Denver') FROM source_table LIMIT 1;{code}
*1970-01-16 14:39:21.215*
"Converting" to a float provides a workaround:
{code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss') * 1.0,'America/Denver') FROM source_table LIMIT 1;{code}
*2012-09-27 15:53:35.0*
As does "adding" nano seconds:
{code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss') * 1000,'America/Denver') FROM source_table LIMIT 1;{code}
*2012-09-27 15:53:35.0*
This problem may be at the heart of HIVE-3454 as well.
> to_utc_timestamp() does not properly handle UNIX timestamp conversions without nanoseconds
> ------------------------------------------------------------------------------------------
>
> Key: HIVE-3510
> URL: https://issues.apache.org/jira/browse/HIVE-3510
> Project: Hive
> Issue Type: Bug
> Components: UDF
> Affects Versions: 0.9.0
> Environment: Ubuntu LTS 10.04
> Reporter: Richard Nadeau
>
> When attempting to convert a UNIX timestamp to UTC the conversion fails if the input does not include micro or nano seconds:
> {code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss'),'America/Denver') FROM source_table LIMIT 1;{code}
> *1970-01-16 14:39:21.215*
> "Converting" to a float provides a workaround:
> {code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss') * 1.0,'America/Denver') FROM source_table LIMIT 1;{code}
> *2012-09-27 15:53:35.0*
> As does "adding" nano seconds:
> {code}SELECT to_utc_timestamp(unix_timestamp('27/Sep/2012:09:53:35','dd/MMM/yyyy:HH:mm:ss') * 1000,'America/Denver') FROM source_table LIMIT 1;{code}
> *2012-09-27 15:53:35.0*
> This problem may be at the heart of HIVE-3454 as well.
> Documentation here: https://cwiki.apache.org/Hive/languagemanual-types.html#LanguageManualTypes-Timestamps
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira