Yea, it is strange the the Json encoder api doesn’t allow the caller to provide a mashaller for any type. It would be trivial to change the code to do so.
That being said I’m sure you can find custom json libs on the web that will do this. Or fork it yourself - it is not a lot of code. > On Jul 24, 2020, at 11:15 AM, Mike Cohen <m...@velocidex.com> wrote: > > > 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 that >> implements an UnmarshalJSON. Looking at that method, I'm a little >> surprised at what you describe, since it just uses the timezone in the >> JSON 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 > -- > <velo_black_small_full_res.png> > 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. -- 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/A922E625-0344-4ADF-A8C0-17F79AE5809B%40ix.netcom.com.
