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 protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to