Thanks Robert, this is what I ended up doing. I wouldnt say it was
trivial though :-)
https://github.com/Velocidex/json
Thanks and sorry for hijacking this thread. Maybe a suggestion - if
users are not expected to change time.Local maybe it should be made
private or at least wording in the module
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
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
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
On Thu, Jul 23, 2020 at 5:13 PM Michael Cohen 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
> I want to change Local because I want all JSON encoding to be normalized
to UTC and not local time - there does not seem to be a way to do this
(please let me know if I am missing something).
Yes, you are missing something. This is very easy. Do not change Local.
Just use the In() method on
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
On Thu, Jul 23, 2020 at 9:47 AM wrote:
>
> A bit late to the party here but I would like to explore your rational for
> stating that time.Local should not be modified by user code. The code seems
> to suggest this is expected:
>
> https://golang.org/src/time/zoneinfo.go
> ```
>
> // localLoc is
A bit late to the party here but I would like to explore your rational for
stating that time.Local should not be modified by user code. The code seems
to suggest this is expected:
https://golang.org/src/time/zoneinfo.go
```
// localLoc is separate so that initLocal can initialize76 // it
Just wrapping a write with a mutex is not enough; you have to wrap all the
reads as well. In this case that's not possible because there are reads of
time.Local all over the place. Anyway, as has been said, time.Local should
never be written to in user code.
On Fri, Nov 30, 2018 at 7:46 AM Agniva
Can you show us the code ? It would help
Are you trying to set a variable of type time.Location ? Or are you trying
to set time.Local to something else ?
Like Ian said, if you want to change the location of a specific time value,
use the In method.
> But there are lots of place that
* Ian Lance Taylor [181130 01:01]:
> On Thu, Nov 29, 2018 at 9:47 PM wrote:
> > The feature of golang is goroutine, and it is a normal situation that get
> > time in different goroutine.
> > But only can set time.Location in one goroutine. So the Data Race is
> > inevitable.
> >
> > And there
On Thu, Nov 29, 2018 at 9:47 PM wrote:
>
> My go version is 1.11.
>
> When I set time.Location, then …
>
> ==
> WARNING: DATA RACE
> Write at 0x02e275d0 by main goroutine:
> vcs.taiyouxi.net/platform/planx/timeutil.SetTimeLocal()
>
>
My go version is 1.11.
When I set time.Location, then …
==
WARNING: DATA RACE
Write at 0x02e275d0 by main goroutine:
vcs.taiyouxi.net/platform/planx/timeutil.SetTimeLocal()
14 matches
Mail list logo
