Feature request: native types for timestamps and durations

[albertito]

Hi!

There are standard messages for timestamps and durations:
https://github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto
https://github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto

At the moment, using these from Go is a bit cumbersome and requires manual work and boilerplate to conver them to and from native types.

Having the proto3 generator using native types for those well known messages would make them much nicer to use from Go.

Thanks!

[albertito]

Somehow I managed to miss #49 which was quite similar.
It was folded onto #50, you may want to do fold this one too.

[dsymonds]

Yes, this is #50.

[edrex]

I read this issue as requesting to use time.Time and time.Duration for Timestamp and Duration fields, which AFAICT #50 isn't about. I gather the reason for not using the native types is that not all time.Times are convertible to Timestamp, is that correct?

[bcmills]

I gather the reason for not using the native types is that not all time.Times are convertible to Timestamp, is that correct?

That seems like only a secondary issue. (Not all Go string values are valid UTF-8 for protobuf string fields, but we allow them anyway - we can always reject invalid encodings by returning an error from proto.Marshal.)

I think the more significant issue is that some programs copy (subsets of) protocol messages to other protocol messages. For some subset of those programs, (un)marshaling all the way through time.Time would add needless overhead.

[mattwilliamson]

I'd say the needless overhead is making us redefine entire new structs and copying every field of the protobuf to it just so we can persist in Google Datastore or Google Spanner. Super frustrating. We already have this datetime fragmentation in java and c++... please don't carry the torch to Go. Don't make program in circles for "some subset of those programs".