[
https://issues.apache.org/jira/browse/KUDU-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15472449#comment-15472449
]
Todd Lipcon commented on KUDU-1594:
-----------------------------------
Hmm.. have mixed feelings about that. We could do it somewhat compatibly (eg on
upgrade just treat all timestamp columns as INT64) but the extra code to add
that compat shim is somewhat painful. And I think there is some benefit in the
metadata that says that a given int64 is a timestamp and not just a random int.
[~dralves] what do you think? IIRC you were the one who added TIMESTAMP
initially
> Rename TIMESTAMP type to avoid confusion with other timestamp types
> -------------------------------------------------------------------
>
> Key: KUDU-1594
> URL: https://issues.apache.org/jira/browse/KUDU-1594
> Project: Kudu
> Issue Type: Improvement
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
>
> Kudu aims to be part of the Hadoop ecosystem, and other tools in the Hadoop
> ecosystem store timestamps differently than Kudu. For example:
> - Parquet has TIMESTAMP_MILLIS which is milliseconds since the Unix epoch.
> - Impala internally stores a {64-bit nanoseconds since midnight, 32-bit
> Julian day number}, and when storing in Parquet, uses Parquet's INT96 type to
> store this.
> - Hive internally uses a 32-bit seconds-since-Unix-epoch, plus an optional
> nanoseconds component
> To avoid adding to the confusion, we should name our time more explicitly (eg
> UNIX_MICROTIMESTAMP or UNIXTIME_MICROS or somesuch)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
