Matt’s formatting example suggests interval arithmetic for time. That is a nice idea.
On Sat, Nov 28, 2020 at 2:22 AM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > It would also be possible to implement `json.Marshaler` to use a different > time format. In particular, it might be reasonable to encode the zero > value of time.Time as `null`, instead of a string (though mixed types in > json messages are… icky). > > Personally, I'm always very cautious about encoding and decoding times. > There isn't really a standard way to transmit timezone information, > especially as timezone definitions can even change over time, AIUI. So, > even if you specify which timezone a point in time should be in, you can't > rely on the receiver of the message having the same understanding of that > timezone. > > Using UTC for storage and transmission is probably a better option. You > essentially treat the stored data purely as "a point in time", while > timezone info is specific to the presentation. A time.Time isn't just a > point in time, though, so if you really marshal "a time.Time", you have to > somehow include timezone info - so I kinda understand why the default > MarshalJSON method doesn't convert it to UTC first. > > On Sat, Nov 28, 2020 at 10:35 AM Matt Harden <matt.har...@gmail.com> > wrote: > >> >> >> On Fri, Nov 27, 2020 at 4:14 PM 'Robert Ma' via golang-nuts < >> golang-nuts@googlegroups.com> wrote: >> >>> Is this because the 2-second offset of LMT gets lost in RFC 3339 >>> representation? >>> >> >> Yes, that's exactly it. >> >> >>> On Fri, Nov 27, 2020 at 6:33 PM Robert Ma <rober...@google.com> wrote: >>> >>>> Hi all, >>>> >>>> Time is complicated. >>>> >>> >> Wibbly-wobbly, even. >> >> Today I found myself in a rabbit hole. For some unrelated reason, I got a >>>> time value in a non-UTC location that's otherwise zero (IsZero=true). This >>>> value doesn't seem to survive a roundtrip to JSON. See this playground for >>>> a minimal reproduction: https://play.golang.org/p/QdglfKYkstS >>>> >>>> Is this expected, a bug, or an undefined behaviour? I checked RFC 3339, >>>> which time uses as the JSON serialization format, and it seems to support >>>> 0000AD to 9999AD, but I have to admit I know little about time. >>>> >>> >> RFC 3339 doesn't support sub-minute timezone offsets, so it's not >> possible to format the LMT zone precisely. >> >> I am concerned that the time printed is incorrect by 2 seconds in this >> case, and (I imagine) could be anywhere from 0 to 59 seconds off depending >> on the particular sub-minute timezone offset used. That seems like a real >> bug, and I don't know what a proper fix would look like. Perhaps when the >> timezone is formatted in numeric form, the printed time should be adjusted >> to account for the loss of precision in the zone info. In your case this >> would print "0000-12-31T19:04:00-04:56" instead >> of "0000-12-31T19:03:58-04:56". That solution has its own issues though. >> >> You probably should only use IsZero() to detect uninitialized time >> values; never on a value that's been parsed from any source, even JSON. >> >> To get arbitrary time values to survive a JSON round trip, I think using >> UTC exclusively would be the best option. >> >> >>>> Cheers, >>>> Robert >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CAOPAaN%2BWvZ73Z-oMVaGmDt-Gr5DEk7ZtQeU43x5fKrCFW42%3DqQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/golang-nuts/CAOPAaN%2BWvZ73Z-oMVaGmDt-Gr5DEk7ZtQeU43x5fKrCFW42%3DqQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CALRNMm0VN8030%2BQLY0sLr%2BuHfz4WoG7NfWe1RUHj-d2Zqh393Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CALRNMm0VN8030%2BQLY0sLr%2BuHfz4WoG7NfWe1RUHj-d2Zqh393Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFx13J%3DiSx7y_hPKNFd8WPO9gVSUz9H_PKsNKjfgnNMPA%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFx13J%3DiSx7y_hPKNFd8WPO9gVSUz9H_PKsNKjfgnNMPA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALoEmQyuZKDX%3Dn2J2yCmUYNPo_-txZLG0jAhva7WaU7VAyTH5g%40mail.gmail.com.
