Always serialise t.UTC()?
On 24/07/2020 04:26, Mike Cohen 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
<mailto: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
--
*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
<mailto: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
<https://groups.google.com/d/msgid/golang-nuts/55b1098d4ff2518143b249b4587b36b527797896.camel%40velocidex.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/d1075c07-991e-2506-29a1-7847df4cda66%40multiplay.co.uk.
