hive-dev mailing list archives

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

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

Ryan Harris commented on HIVE-3822:
-----------------------------------

I understand that is the way the code *does* work, the question, in my mind...is that the
way it *should* work?

I understand that timestamps are inherently timezone-less, and if you want/need to deal with
timezone conversions that is the reason the from_utc_timestamp() and to_utc_timestamp() functions
were created.

In this case, the result of the query is going to change/depend on the local timezone of the
cluster you are running the query against.

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

If you WANT/NEED to alter the conversion of the timestamp to account for a specific timezone,
shouldn't you use from_utc_timestamp()? 

As it is, because of the implicit cast() conversion that is occurring when to_utc_timestamp()
is called, the results of: to_utc_timestamp(1355944339.0, 'GMT')
STILL varies based on the timezone of the JVM/cluster where the function is called...that
makes NO sense.

IMO, the cast() function should assume that the epoch integer/double passed to it is timezone-less
and NOT apply any skew/adjustment based on the whatever the local timezone of the JVM might
be.
                
> 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