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 >
