Protocol Buffers v3.0.0 released
They added a feature that impressively fails to interoperate with the rest of the world.> Added well-known type protos (any.proto, empty.proto, timestamp.proto, duration.proto, etc.). Users can import and use these protos just like regular proto files. Additional runtime support are available for each language.From timestamp.proto:  // A Timestamp represents a point in time independent of any time zone
  // or calendar, represented as seconds and fractions of seconds at
  // nanosecond resolution in UTC Epoch time. It is encoded using the
  // Proleptic Gregorian Calendar which extends the Gregorian calendar
  // backwards to year one. It is encoded assuming all minutes are 60
  // seconds long, i.e. leap seconds are "smeared" so that no leap second
  // table is needed for interpretation.

Nice, sort of -- all UTC times are representable.  But you can't display the time in normal human-readable form without a leap-second table, and even their sample code is wrong is almost all cases:  //     struct timeval tv;
  //     gettimeofday(&tv, NULL);
  //
  //     Timestamp timestamp;
  //     timestamp.set_seconds(tv.tv_sec);
  //     timestamp.set_nanos(tv.tv_usec * 1000);

That's only right if you run your computer in Google time.  And, damn it, Google time leaked out into public NTP the last time their was a leap second, breaking all kinds of things.Sticking one's head in the sand and pretending there are no leap seconds is one thing, but designing a protocol that breaks interoperability with people who don't bury their heads in the sand is another thing entirely.Edit: fixed formatting