[
https://issues.apache.org/jira/browse/HIVE-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545169#comment-13545169
]
Mark Grover commented on HIVE-3822:
-----------------------------------
{quote}
select cast(0.0 as timestamp) from test limit 1
1969-12-31 17:00:00
select cast('1970-01-01 00:00:00' as timestamp) from test limit 1
1970-01-01 00:00:00
{quote}
We can't talk about human readable timestamps without referring to a particular
timezone. When your query is {{select cast('1970-01-01 00:00:00' as timestamp)
from test limit 1}}, you are implicitly referring to your default timezone (you
can make an argument that implicit reference should be to GMT timezone here but
like I said before that's historically not been the case with database systems)
and therefore the results are different. The first query creates a query that's
01/01/1970 midnight in UTC while the second creates the same time but in Denver.
bq. The problem is that cast(STRING datetime to TIMESTAMP) produces different
results from cast(int/float datetime to TIMESTAMP)
That would always be the case (unless your system timezone is UTC) since the
STRING datetime refers to your system timezone while the int/float datetime
always refers to UTC timezone.
> 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
