Re: [go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

2020-11-29 Thread Michael Jones 
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 
> 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  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
 AD to AD, 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 "-12-31T19:04:00-04:56" instead
>> of "-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
>>> 
>>> .
>>>
>> --
>> 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
>> 
>> .
>>
> --
> 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
> 
> .
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

--

Re: [go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

2020-11-28 Thread 'Axel Wagner' via golang-nuts 
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  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  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
>>> AD to AD, 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 "-12-31T19:04:00-04:56" instead
> of "-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
>> 
>> .
>>
> --
> 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
> 
> .
>

-- 
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.

Re: [go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

2020-11-28 Thread Matt Harden 
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  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
>> AD to AD, 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 "-12-31T19:04:00-04:56" instead
of "-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
> 
> .
>

-- 
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.

[go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

2020-11-28 Thread b.ca...@pobox.com 
I didn't think that AD was a thing, even though RFC 3339 says it is.

Wikipedia says that dates in Common Era 
 and Dionysius BC/AD 
 are equivalent,  and that 1BC 
led straight onto 1AD.

-- 
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/540a6f0f-df1a-4e0f-9b74-a216e8e0fb45n%40googlegroups.com.

[go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

2020-11-27 Thread 'Robert Ma' via golang-nuts 
Is this because the 2-second offset of LMT gets lost in RFC 3339
representation?

On Fri, Nov 27, 2020 at 6:33 PM Robert Ma  wrote:

> Hi all,
>
> Time is complicated.
>
> 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
> AD to AD, but I have to admit I know little about time.
>
> 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.