[
https://issues.apache.org/jira/browse/AVRO-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094128#comment-14094128
]
Dmitry Kovalev commented on AVRO-739:
-------------------------------------
bq. I think the right way to handle this is to use the zone-independent
date/time types and an application-level zone implementation. These cases
aren't very common, as you noted, and I think having a timestamp with zone
logical type allows people to get around best practices and doesn't deliver a
better solution for people that actually need to represent the zone. It may be
slightly easier to represent the type in a single field, but size is
significantly larger and the value only has significance when interpreted at
the application layer anyway.
In environments providing "rich" support for date-time related types (such as
Joda Time / Noda time), this actually translates directly into the likes of
ZonedDateTime, and can be handled on Avro level, e.g. using Specific the
generated objects can expose ZonedDateTime properties instead of strings. This
is what I do so it does deliver a better solution for me.
Happy to drop it from the spec anyway.
> 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
> Fix For: 1.7.8
>
> Attachments: AVRO-739-datetime-spec.xml.patch, AVRO-739.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
