[
https://issues.apache.org/jira/browse/AVRO-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079790#comment-14079790
]
Dmitry Kovalev commented on AVRO-739:
-------------------------------------
Hi guys,
I am currently using an attribute-based approach which builds upon this
discussion plus the one about decimal type - and extends it to support various
types of date/time information - roughly following the JodaTime/NodaTime
classification.
I distinguish a few logicalTypes (this defines what it represents e.g. just a
date, an instant in time, a time in specific zone etc), each of which can have
one or more logicalEncoding (this defines which primitive type is holding the
info, and how it is encoded).
For example (using IDL syntax, sorry I'm not good at emitting JSON):
1) DateTimeInstant - represents exact moment in time - millis, UTC or specific
offset are all equivalent representations
@logicalType("DateTimeInstant") @logicalEncoding("millis-unix-epoch") long
timestamp; //just a usual long with number of millis since unix epoch
@logicalType("DateTimeInstant") @logicalEncoding("ISO8601-datetime-offset")
string asOfDateTime; //must be ISO full date and time including offset or UTC
symbol i.e. YYYY-MM-DDThh:mm:ss.xxx+-hh:mm or YYYY-MM-DDThh:mm:ss.xxxZ
2) LocalDate - represents a calendar date, time is not important/not defined,
so day start differences due to timezones are not directly applicable
@logicalType("LocalDate") @logicalEncoding("ISO8601-date") string
settlementDate; //must be ISO local date without any time, offset or UTC
symbol, i.e. YYYY-MM-DD
3) ZonedDateTime - represents not just a moment in time, but preserves the
information about which time zone it was defined originally - which may be
important
@logicalType("ZonedDateTime") @logicalEncoding("ISO8601-datetime-timezone")
string optionExpiration; //must be ISO local date and time without any offset
or UTC symbol, followed by a space and either "UTC" or an IANA tzdb id such as
"Europe/London", "Europe/Moscow", i.e. YYYY-MM-DDThh:mm:ss.xxx zzzzz/zzzzz
All of the above logicalEncodings are sufficiently well-defined to be
interpreted easily and unambiguously on any platform, for example I use the
following:
ISO8601-datetime-offset:
in JodaTime: ISODateTimeFormat.dateTimeParser().parseDateTime(),
ISODateTimeFormat.dateTime().print()
in NodaTime:
InstantPattern.ExtendedIsoPattern.Parse((string)inputValue).GetValueOrThrow(),
InstantPattern.ExtendedIsoPattern.Format(instant)
ISO8601-date:
in JodaTime: ISODateTimeFormat.localDateParser().parseDateTime(),
ISODateTimeFormat.date().print()
in NodaTime:
LocalDatePattern.IsoPattern.Parse((string)inputValue).GetValueOrThrow(),
LocalDatePattern.IsoPattern.Format(localDate)
ISO8601-datetime-timezone:
in JodaTime: sb.append(zdt.toLocalDateTime().toString()).append("
").append(zdt.getZone().getID()),
String[] parts = cs.toString().split(" ");
LocalDateTime localDt =
ISODateTimeFormat.dateTimeParser().parseDateTime(parts[0].trim()).toLocalDateTime();
DateTimeZone tz = DateTimeZone.forID(parts[1].trim());
in NodaTime:
ZonedDateTimePattern.ExtendedFormatOnlyIsoPattern.Format(zonedDateTime),
var parts = (inputValue as string).Split(' ');
var localDateTime =
LocalDateTimePattern.ExtendedIsoPattern.Parse(parts[0].Trim()).GetValueOrThrow();
DateTimeZone tz =
NodaTime.DateTimeZoneProviders.Tzdb[parts[1].Trim()];
return localDateTime.InZoneStrictly(tz);
This is backwards compatible as older code can ignore the attributes and assume
the encoding, while newer code can make use of this metainformation - for
example it can be used to detect the end type in generic code, or during
codegen to generate properly typed properties.
If you like the general idea, then I would suggest to just document these
(happy to rename/amend/extend them) to provide a common basis, without any code
for the moment - in the spirit of the decimal type.
Any thoughts welcome.
Thanks,
Dmitry
> 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 was sent by Atlassian JIRA
(v6.2#6252)
