[
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
