To be clear, the time.MarshalJSON() function produces valid RFC 3339 timestamps which allow arbitrary timezones. This means that local time offset is used in the string representation. Although all representations are technically equivalent their string form is not so we need to do special parsing to compare them (and users get really confused as well). Here is an example - https://play.golang.org/p/hELVEI1tGJd when I run it I get {"A":6,"B":"2009-11-11T10:00:00+11:00"} for Australia time, but {"A":6,"B":"2009-11-10T18:00:00-05:00"} for America/New_York. I am aware I can use the .In() method to cast the time.Time object into different timezone but this is the whole issue - I need to search through all the struct fields, expand slices, recurse through maps etc just to find any time.Time objects and change them **before** I call json.Marshal(). I usually get the times from a struct in another library so I have no control over how these times are made for example consider this https://play.golang.org/p/HmGREBF2Hbd where I call an out of tree library to build a struct then just want to dump it - I have no control over the encoding. I think this is a actually a limitation in the json strategy of encoding based only on types and not on context. The TZ issue is just a manifestation of that - even if there was a safe way to set TZ in a running program, in a multithreaded program all json encoders would be forced to use the same local TZ because encoding goes with type and not with context. Thanks.Mike
On Thu, 2020-07-23 at 20:02 -0700, Ian Lance Taylor wrote: > On Thu, Jul 23, 2020 at 5:13 PM Michael Cohen <scude...@gmail.com> > wrote: > > Thanks Ian, this does not work as I mentioned because there is no > > way to guarantee that my init function will run before any of my > > libraries creating a time object (which many do as they start > > various background tasks). > > Doing what you say is fragile because even if it appears to work, > > one day I might link a library and it will mysteriously break > > randomly (this happened to us previously). > > Is this a bug in the time package? Or simply a bug or design > > shortfall in the json package? One way I thought to fix this issue > > is to simply fork the json encoder and handle time.Time structs > > specifically, but this obviously does not scale to eg yaml encoders > > etc. > > I don't think it's a shortfall in the encoding/json package as > such,as that package knows nothing about times. It's the time > package thatimplements an UnmarshalJSON. Looking at that method, I'm > a littlesurprised at what you describe, since it just uses the > timezone in theJSON string. It doesn't use the local timezone as far > as I can see.Can you show a small program that demonstrates the > problem? > Ian -- Mike Cohen Digital Paleontologist Velocidex Enterprises https://www.velocidex.com +61.470238491 -- 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/55b1098d4ff2518143b249b4587b36b527797896.camel%40velocidex.com.
