Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # dev >> Re: [jira] [Commented] (AVRO-739) Add Date/Time data types


Copy link to this message
-
Re: [jira] [Commented] (AVRO-739) Add Date/Time data types
For what it's worth, I'd like to see these as fundamental avro primitive
types (along with some form of decimal).  We use the emitted specific types
in both java and C# and having to wrap them and incur the overhead of
constantly converting back and forth from strings (today) adds unnecessary
complexity and overhead.  Database systems treat these as primitives; it
would be nice if avro did as well.

Thanks,
Bill
On Fri, Sep 6, 2013 at 5:03 PM, Scott Carey (JIRA) <[EMAIL PROTECTED]> wrote:

>
>     [
> https://issues.apache.org/jira/browse/AVRO-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13760779#comment-13760779]
>
> Scott Carey commented on AVRO-739:
> ----------------------------------
>
> {quote}
> These seem like two different external representations of the same thing.
> A time plus a timezone can be losslessly converted to a UTC time. You do
> lose the original timezone, but dates and times are usually displayed in
> the timezone of the displayer, not where the time was originally noted.
> {quote}
>
> I completely agree for use cases where the time is being displayed to a
> user, but there are use cases where the loss of the original time zone is
> not acceptable.   One could log another field with the timezone identifier
> for these.    The use case for a UTC timestamp is more broadly applicable.
>  I do not think we need to implement the one that also persists timezone
> now, but I do think we need to make sure that if we did implement such a
> thing in the future, that the names for these two things would be
> consistent.  If we name this "Datetime" we are implying it has relation to
> dates, which implies relationship to timezones.
>
> With respect to the SQL variants, I see only two that represent a single
> point in time. Three are either dates or times and not the combination
> (e.g. "January 7, 2100", representing a time with granularity of one day,
> or "5:01" -- a time of day, respectively).
>
> The two SQL equivalents are TIMESTAMP and TIMESTAMP WITH TIMEZONE.   This
> proposal covers TIMESTAMP, roughly.  I am suggesting we reserve space for a
> future TIMESTAMP WITH TIMEZONE.   We could adopt the names for consistency.
>
> "timestamp"
> and
> "timestamptz"
>
> There is also the question of serialization in JSON form.  A long in
> binary form makes sense, but in JSON, an ISO8601 string might be more
> useful.
>
> > Add Date/Time data types
> > ------------------------
> >
> >                 Key: AVRO-739
> >                 URL: https://issues.apache.org/jira/browse/AVRO-739
> >             Project: Avro
> >          Issue Type: New Feature
> >          Components: spec
> >            Reporter: Jeff Hammerbacher
> >         Attachments: AVRO-739.patch
> >
> >
>
>
> --
> 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
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB