Closed kpelzel closed 1 year ago
Hi, this is determined by the wider protobuf project. See https://developers.google.com/protocol-buffers/docs/proto3#json:
Uses RFC 3339, where generated output will always be Z-normalized and uses 0, 3, 6 or 9 fractional digits. Offsets other than "Z" are also accepted.
Thus, we should always encode in UTC, but accept UTC and other timezones. If that's not the behavior today, then that's a bug. Any changes to the behavior needs to be discussed at the wider protobuf project level and not here.
Ah thank you, I didn't see the RFC3339 requirement.
Is there a reason we can't encode in another timezone if decoding another timezone is accepted?
Is there a reason we can't encode in another timezone if decoding another timezone is accepted?
I don't have a concrete answer, but I suspect it's because the philosophy of Postel's Law motivated the design of protobuf:
"be conservative in what you send, be liberal in what you accept"
I personally disagree with that design mentality, but it is widely held by many.
Is your feature request related to a problem? Please describe. When marshaling protobuf to/from json, timestamps are locked into being RFC3339 in UTC.
Describe the solution you'd like I would like to be able to able to specify a timezone location and a timestamp format in
MarshalOptions
andUnmarshalOptions
Additional context I have a working and tested solution that I'll submit to Gerrit.