[
https://issues.apache.org/jira/browse/KUDU-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15478182#comment-15478182
]
Todd Lipcon commented on KUDU-1594:
-----------------------------------
Sorry, just saw your comment, David. Assumed you're OK with the rename because
you +2ed the patch :)
bq. TIMESTAMP's current format was created to match postgresql's timestamp
without timezone, which Impala was maybe going to match later
Yea, having chatted with [~mjacobs] about this, it sounds like there's still
some chance that Impala will add an equivalent type. But, they can't rename
their 'TIMESTAMP' type either without compatibility issues, so that new type
will have to get a new name (perhaps UNIXTIME_MICROS?)
This rename also leaves us open in the future to add a new type, stored in an
int96, which matches Impala's.
> 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
> Fix For: 1.0.0
>
>
> 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)
