Comment #2 on issue 324 by Grigand: Feature: Add a new primitive type for a
DateTime format
http://code.google.com/p/protobuf/issues/detail?id=324
I think adding a binary datetime type, especially based on the aging and
awful C conventions, is a terrible idea. It's just not adequate for a
host of time representations.
This is of course the 'can-o-worms' I spoke of. Though I agree it's
incomplete information, it does transfer the date+time value. If your
specific application has need of more, another field can specify the UTC
Offset, Zone Id, Olson ID, or whatever serves your specific requirements.
Example:
message Document {
required datetime utc_modified_date = 1;
required datetime utc_created_date = 2;
optional int32 utc_offset_minutes = 3;
}
This isn't as 'ideal' as being able to define both in one field; however,
it is unambiguous enough for a public facing API. I don't need to document
in what format the date+time part should be specified. The use of
utc_offset_minutes should also be obvious to any consumer. This, IMO,
get's us "close enough" without getting tied up in months of debate about
the perfect date+time representation. I'd even be OK with moving date+time
as ISO8601/RFC3339 string data, anything just something standard :)
My preference is still the later option, a packed field based 'observed
time', rather than using an 'incremental time'. Incremental time does a
great job at sorting and calculating (add, subtract, etc) date+time. An
observed time on the other hand is horrible thing to add/subtract and may
even be difficult to sort. Yet the observed time is still superior for
transporting date+time which is the problem protobuffers is designed to
solve.
Moreover, I don't how it will save the bug filer any work whatsoever,
since not all of his target formats ...
This is somewhat off topic. I don't want this issue to get bogged down in
transcoding of protobuffers into other protocols. The *real problem* is
that a public API built on protobuffers can not support date+time values in
a standard way.
..., since not all of his target formats use the same date/time
representation anyway.
The time/energy saved has to do with the fact that the descriptor and
datatype of the proto do not reflect whether the field is a date+time or
not. This means that serializers that are crawling field values encounter
a string, or uint64, not a language specific date+time. They must either
guess by convention or define field extensions that supply the additional
information.
You are correct that I have varying requirements in target formats, this is
the nutshell of my issue. I need to convert the date+time values into
various formats (ISO8601/RFC3339, JSON Date(), or BSON Unix epoch +
milliseconds) to comply with other protocols. This means I must know it's
a date+time, how to extract it into a language-specific type, and then
convert it into the appropriate form for the target protocol.
Again, transcoding between protocols is just a very small part of the
overall problem.
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
