hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Grover (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-3822) Casting from double to timestamp type seems inconsistent
Date Sat, 05 Jan 2013 20:20:12 GMT

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

Mark Grover commented on HIVE-3822:
-----------------------------------

bq. In my opinion the result of a query should NOT depend on the time configuration of your
server/cluster.

Ryan, that's presently not the case. And, that's not just Hive but other databases as well.
MySQL, for example, uses the default timezone of the system for unix timestamp to human-readable
conversions as well.

What you are saying about to_utc_timestamp() is most likely a bug in the UDF code itself.
If so, please file a separate JIRA for that. In my personal opinion, a bug in how to_utc_timestamp
works doesn't warrant changing the behavior of Timestamp type to use GMT timezone when converting
to human readable format instead of the default system time zone.

I haven't looked at the code but I would expect to_utc_timestamp() to return the same result
as long as the first parameter represents the same logical timestamp regardless of how it
is expressed - integer timestamp or timestamp type. Are you saying the result is different
depending on the representation being passed as the first parameter?
                
> Casting from double to timestamp type seems inconsistent
> --------------------------------------------------------
>
>                 Key: HIVE-3822
>                 URL: https://issues.apache.org/jira/browse/HIVE-3822
>             Project: Hive
>          Issue Type: Bug
>    Affects Versions: 0.9.0
>            Reporter: Mark Grover
>            Assignee: Mark Grover
>
> {code}
> select cast(1355944339 as timestamp) from decimal_3 limit 1;
> 1970-01-16 08:39:04.339
> select cast(1355944339000 as timestamp) from decimal_3 limit 1;
> 2012-12-19 11:12:19
> select cast(1355944339.123456789 as timestamp) from decimal_3 limit 1;
> 2012-12-19 11:12:19.1234567
> {code}
> If specifying the unixTimestamp without a decimal point, we need to specify the millisecond
timestamp. If specifying with a decimal point, we need to specify only the second timestamp
and the rest goes after decimal. Moreover, it seems like some precision is lost (notice '89'
are lost in the last query.

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

Mime
View raw message