time: js/wasm sets time.Local to a UTC offset instead of the actual timezone

[Splizard]

In time/zoneinfo_js.go the local timezone is determined by the UTC offset returned by the JS call:

(new Date()).getTimezoneOffset()

However UTC offset != timezone and this behaviour causes issues with displaying 'daylight savings' times. This behaviour is unexpected and undocumented and I would expect that time.Local is set to the JS environment's timezone (where available) instead of the current UTC offset.

The timezone can be determined in JS with the Internationalization API:

Intl.DateTimeFormat().resolvedOptions().timeZone

As long as the tzdata package has been imported/embedded and the its init function runs first, adding the following code to the beginning of initLocal should (in theory) fix this issue.

func initLocal() {
	if intl := js.Global().Get("Intl"); !intl.IsUndefined() {
		var err error
		tz := js.Global().Get("Intl").Call("DateTimeFormat").Call("resolvedOptions").Get("timeZone").String()
		Local, err = LoadLocation(tz)
		if err == nil {
		    return
		}
	}
	...

[agnivade]

The internationalization API was the initial approach that was used. But then there was a bit of back and forth in the CL https://go-review.googlesource.com/c/go/+/143577 and it was decided to parse the timezone offset from new Date().

cc @neelance

[neelance]

I think the real issue here is that there was no https://golang.org/pkg/time/tzdata/ yet, so the wasm binary never shipped with any timezone data included. Calling LoadLocation simply did not work on wasm.

Now that 6d63a74 added time/tzdata we could reconsider this.

[kirillrdy]

if someone finds this

for GOOS=js GOARCH=wasm

time.LoadLocation doesnt work
but you can import _ "time/tzdata" in your main and then time.LoadLocation will work