[
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
