4 ms·
Protobuf doesn’t have a date/date time/time type which means you get dates encoded as strings and all the fun that entails. Not saying that either is better bu
by sandermvanvliet 5y ago
Protobuf doesn’t have a date/date time/time type which means you get dates encoded as strings and all the fun that entails.
Not saying that either is better but just sometimes you actually do want more types instead of less.
- Matthias247 5y agoWell there is Timestamp defined as a well known type which is available to all implementations despite not being a primitive type [1]. Plus one is obviously able to define any other custom types if necessary- eg as seen in [2]. [1] https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#google.protobuf.Timestamp https://developers.google.com/protocol-buffers/docs/referenc... [2] https://github.com/googleapis/googleapis/blob/master/google/type/datetime.proto https://github.com/googleapis/googleapis/blob/master/google/...
- sandermvanvliet 5y agoOk my bad, I was looking to quickly through the base types in the proto reference
- ithkuil 5y agoWell known types strike an interesting balance between IDL and compiler simplicity vs ergonomics. For example maps were added in proto3. They use the same binary encoding as the proto2 pattern that you could use to implement mappings (repeated field of key value pair messages). Adding maps as first class citizen in the IDL dealt with the lack of type parameters that would have been needed to implement a Map well-known type.
- stjohnswarts 5y agoTime doesn't have to be hard though? Just stick to an international standard and stick to it. Reject anything that doesn't comply with your chosen format. It's better to fail than to continue running after you receive garbage data. I admit we have a close system at work be we never have time issues.