[
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
