Comment #2 on issue 324 by Grigand: Feature: Add a new primitive type for a DateTime format

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
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to