AFAIK the answer is no. A lot of the value of protocol buffers derives from
keeping their functionality simple. There are plenty of all singing/all dancing
serialization frameworks already. ;-)
I think date in particular is fraught with peril. I'd recommend against
encodung them as strings. What I've done is encode all date/time date as
int64's, with the value being milliseconds since the UTC epoch. Even that has
complications, but it is a "good enough" approach.
In theory, BigInteger could be encoded using the existing varint encoding, so
you could write a module fairly easily, and of course once you can do that and
encode floats BigDecimal is straightforward. Alternatively you could store the
raw bytes of the BigDecimal in a raw field.
To make BigInteger a part of the standard protocol buffer definition, there's a
lot more work involved, and a price to be paid. The challenge is having a
consistent, tested, efficient mechanism for handling this in the plethora of
languages that protocol buffers support. Without that, you undermine the
ability of protocol buffer's to always be parsed consistently everywhere, which
is a very important feature. This is a big undertaking, particularly given that
some languages don't have a standard type equivalent. Given that it is a data
type so much less often needed, You can see why it likely doesn't make a lot of
sense to put it in the standard implementation/language.
On Apr 4, 2012, at 12:37 PM, jhakim <jawaid.ha...@codestreet.com> wrote:
> Any plans to provide out-of-the-box for commonly used data types such
> as Date (encoded as String) and BigDecimal/BigInteger types? Seems
> this would be of interest to a lot of users.
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to firstname.lastname@example.org.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at