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.

Sign up for GitHub

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

Jump to bottom

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

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

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

Splizard opened this issue Feb 19, 2021 · 3 comments
Labels
arch-wasm WebAssembly issues NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-JS
Milestone
Unplanned

Comments

@Splizard
Copy link

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
		}
	}
	...
@seankhliao seankhliao added arch-wasm WebAssembly issues NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-JS labels Feb 19, 2021
@agnivade
Copy link
Contributor

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

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
@fanaticscripter
port/wasm/rockets-tracker: fix missions in launch log placed in wrong…
3c43c3b 
… 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...
MoT3rror pushed a commit to MoT3rror/EggContractor that referenced this issue May 3, 2021
@fanaticscripter @MoT3rror
port/wasm/rockets-tracker: fix missions in launch log placed in wrong…
a277436 
… 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...
fanaticscripter added a commit to fanaticscripter/Egg that referenced this issue May 31, 2021
@fanaticscripter
port/wasm/rockets-tracker: fix missions in launch log placed in wrong…
0e3f8fd 
… 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...
@kirillrdy
Copy link

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

@seankhliao seankhliao added this to the Unplanned milestone Aug 20, 2022
carpetsage pushed a commit to carpetsage/egg that referenced this issue Dec 19, 2022
@fanaticscripter
port/wasm/rockets-tracker: fix missions in launch log placed in wrong…
275c535 
… 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
Assignees
No one assigned
Labels
arch-wasm WebAssembly issues NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-JS
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@kirillrdy @neelance @agnivade @Splizard @seankhliao