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 -- 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/CAOyqgcVP6Sm5ZjRr_hCQBxY_e61TX8ugPsnxO5S%2BUO2zx3%2Bzxw%40mail.gmail.com.
