[protobuf] Re: Issue 324 in protobuf: Feature: Add a new primitive type for a DateTime format
Comment #8 on issue 324 by wouter.b...@gmail.com: Feature: Add a new primitive type for a DateTime format https://code.google.com/p/protobuf/issues/detail?id=324 Temporenc (http://temporenc.org) is a comprehensive binary encoding format for dates and times that tries to solve the problem discussed in this issue. It is designed to be embedded into protobufs (or other embedding formats). -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: Issue 324 in protobuf: Feature: Add a new primitive type for a DateTime format
Comment #7 on issue 324 by apenneba...@42six.com: Feature: Add a new primitive type for a DateTime format http://code.google.com/p/protobuf/issues/detail?id=324 Yes, please! Datetimes are very common fields, historically implemented with a slew of incompatible formats. Protocol Buffers is intended to help data travel between systems in a language-agnostic way, so the current solution of rolling your own format is antithetical. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/groups/opt_out.
[protobuf] Re: Issue 324 in protobuf: Feature: Add a new primitive type for a DateTime format
Updates: Status: Invalid Comment #6 on issue 324 by liuj...@google.com: Feature: Add a new primitive type for a DateTime format http://code.google.com/p/protobuf/issues/detail?id=324 Protobuf library is designed to provides fundamental low-level primitive types. You can use int64 or even bytes for arbitrary data in application layer. -- 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.
[protobuf] Re: Issue 324 in protobuf: Feature: Add a new primitive type for a DateTime format
Comment #5 on issue 324 by lukera...@gmail.com: Feature: Add a new primitive type for a DateTime format http://code.google.com/p/protobuf/issues/detail?id=324 The issue is not about the best representation of the datetime as it is serialised (ms since epoch seems fine to me) it is whether the datetime should be a supported native type, so that the generated classes can have properties that don't require extra handling to convert to a native datetime -- 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.
[protobuf] Re: Issue 324 in protobuf: Feature: Add a new primitive type for a DateTime format
Comment #3 on issue 324 by cms...@gmail.com: Feature: Add a new primitive type for a DateTime format http://code.google.com/p/protobuf/issues/detail?id=324 Can we just have a 64 bit type for 'milliseconds since 1970', as both Java and Javascript like this format? -- 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.
[protobuf] Re: Issue 324 in protobuf: Feature: Add a new primitive type for a DateTime format
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.
