hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arijit Banerjee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-3822) Casting from double to timestamp type seems inconsistent
Date Tue, 18 Jun 2013 03:12:21 GMT

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

Arijit Banerjee commented on HIVE-3822:
---------------------------------------

I think a good approach would be to fix it in a way that it can work with both double and
long values. This is what I did and works for me. Let me know what you think. I also suggested
this in the duplicate issue #HIVE-3454.

In org.apache.hadoop.hive.serde2.objectinspector.primitive PrimitiveObjectInspectorUtils.java
edit getTimestamp method and convert the long object to double.

getTimestamp(Object o, PrimitiveObjectInspector oi)

case LONG:
//Timestamp conversion from LONG is messy. Converting to double.
long tsLongPrimitive=((LongObjectInspector) oi).get(o);
result =TimestampWritable.doubleToTimestamp(tsLongPrimitive*1.0);
break;

                
> 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