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.
On Fri, Sep 6, 2013 at 5:03 PM, Scott Carey (JIRA) <[EMAIL PROTECTED]> wrote:
> Scott Carey commented on AVRO-739:
> 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.
> 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.
> 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
> > 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
> For more information on JIRA, see: http://www.atlassian.com/software/jira