Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Splizard opened this issue Feb 19, 2021 · 2 comments
Open

Comments

@Splizard
Copy link

@Splizard Splizard commented Feb 19, 2021

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
Copy link
Contributor

@agnivade agnivade commented Feb 28, 2021

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
Copy link
Member

@neelance neelance commented Feb 28, 2021

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.

fanaticscripter added a commit to fanaticscripter/EggContractor that referenced this issue Mar 19, 2021
… date...

due to DST.

This is a bug in golang's wasm runtime itself:
golang/go#44408, so we instead move the datetime
handling to JS. And we introduce dayjs since even formatting a date as
YYYY-MM-DD is a royal pain in JS, even in 2021...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants