Electron 32/33 `Intl` API returns `Etc/Unknown` time zone

[xpirt]

Preflight Checklist

• [x] I have read the Contributing Guidelines for this project.
• [x] I agree to follow the Code of Conduct that this project adheres to.
• [x] I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

32.2.3

What operating system(s) are you using?

Windows

Operating System Version

Windows 11 Home Single Language (Build 22631.4391)

What arch are you using?

x64

Last Known Working Electron version

30.5.1

Expected Behavior

Intl.DateTimeFormat().resolvedOptions().timeZone should return "Africa/Johannesburg"

Actual Behavior

Intl.DateTimeFormat().resolvedOptions().timeZone returns "Etc/Unknown"

Testcase Gist URL

No response

Additional Information

It just happens on Windows 11 Home Single Language (Build 22631.4391). On Window 11 Home/Pro works fine. It is working fine on Electron 30.x, as soon as I update to 32 or 33 its breaks. There must be a regression. You can test by opening dev tools and typing Intl.DateTimeFormat().resolvedOptions().timeZone.

[dsanders11]

It just happens on Windows 11 Home Single Language (Build 22631.4391). On Window 11 Home/Pro works fine.

This is a pretty specific situation - can you provide more info that would allow for attempting a repro? Which language is that machine configured for, or does it repro under different languages?

Please test to see if the issue repros in the latest Chromium as well.

[xpirt]

It just happens on Windows 11 Home Single Language (Build 22631.4391). On Window 11 Home/Pro works fine.

This is a pretty specific situation - can you provide more info that would allow for attempting a repro? Which language is that machine configured for, or does it repro under different languages?

It's set to South Africa locale, English language.

Please test to see if the issue repros in the latest Chromium as well.

Works fine on latest Chrome browser (Chromium 130.0.6723.117 Stable). Does not work neither on Electron 33.2.0 (Chromium 130.0.6723.118) nor Electron 32.2.3 (Chromium 128.0.6613.186).

[felixrieseberg]

The Chromium version is likely a misdirection - Chrome uses V8 to determine your timezone, which in turn relies on Unicode ICU (https://v8.dev/docs/i18n).

I haven't checked this myself but here's my theory:

• This is already fixed in ICU
• Chromium 130.0.6723.117 has picked up a newer version of V8/ICU than we at Electron have
• Once we upgrade V8 and thus ICU we will also get a bugfix

Just a guess but a pretty confident one

[xpirt]

The Chromium version is likely a misdirection - Chrome uses V8 to determine your timezone, which in turn relies on Unicode ICU (https://v8.dev/docs/i18n).

I haven't checked this myself but here's my theory:

• This is already fixed in ICU
• Chromium 130.0.6723.117 has picked up a newer version of V8/ICU than we at Electron have
• Once we upgrade V8 and thus ICU we will also get a bugfix

Just a guess but a pretty confident one

Thank you @felixrieseberg! Any chance we can get this fixed soon?

cc @codebytere

[pbarnesp]

thanks all - seeing this issue as well.

• Expected: Europe/London
• Actual: Etc/Unknown

This is for one of 100+ users. In the browser the correct timezone is returned. In the electron app Etc/Unknown is returned.

[xpirt]

Any news?

[KiranNiranjan]

@felixrieseberg I've tested this issue with the following versions and unfortunately, the problem persists. Could someone please investigate this further?

• Electron: 34.0.0
• Chromium: 132.0.6834.83
• Node.js: 20.18.1

Additionally, I've observed the following behaviour: If the user changes the system timezone while the application is running, the change is reflected correctly. However, if the user restarts the application, the timezone reverts to Etc/Unknown.

[xpirt]

Maybe @ckerr can jump in, as he has experience with V8?

ccing @codebytere @dsanders11 @VerteDinde @deepak1556

[sbenmoussati]

We are facing the same issue on Electron 34, any update on this issue?

[xpirt]

Any news?

This is affecting 32.x, 33.x and 34.x and no one is taking care of it?

[xpirt]

Any news? @felixrieseberg @codebytere @dsanders11 @VerteDinde @deepak1556

Can you please check this? It's quite critical, it affects bunch of users and it is reproducible. Can you check if ICU version is updated?

[dsanders11]

@xpirt, what is the latest Electron version you've verified this repros on?

Also, please do not ping multiple maintainers in comments, it does not increase the odds of getting a response and maintainers are already swamped with notifications.

[xpirt]

@xpirt, what is the latest Electron version you've verified this repros on?

Also, please do not ping multiple maintainers in comments, it does not increase the odds of getting a response and maintainers are already swamped with notifications.

Electron 33.2.0 (Chromium 130.0.6723.118)

[dsanders11]

Electron 33.2.0 (Chromium 130.0.6723.118)

Is it fixed on 34 and 35, or you just haven't repro'd it here?

[xpirt]

Sorry, the latest version I tested was 34, not 33. Haven't tested on 35, but given that 31, 32, 33 and 34 versions contain the bug (with no patch) I doubt the 35 fixes it. I am pretty sure the version of ICU is still not up-to-date.

[KiranNiranjan]

This issue persists in the latest versions of Electron (35 and 36), and currently, there is no workaround for affected users.

[xpirt]

Electron 33.2.0 (Chromium 130.0.6723.118)

Is it fixed on 34 and 35, or you just haven't repro'd it here?

It has been confirmed not working on 35 and 36 - should this be escalated? Probably it's an easy fix, if that's confirmed. Why no one is taking care of it? 🥲

[xpirt]

Any news?

[electron-issue-triage[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[sbenmoussati]

bump