Bug 197213 – [INTL] en-NZ locale defaults to en-US locale instead of using en-NZ

• Status: VERIFIED
• Resolution: CONFIGURATION CHANGED
• Component: JavaScriptCore

[Daniel Compton]

When using Intl.DateTimeFormat/Intl.NumberFormat in the New Zealand locale (en-NZ), if you use Intl.DateTimeFormat() or Intl.DateTimeFormat("default"), JavaScriptCore resolves the locale to the en-US locale. This only seems to happen for New Zealand. When macOS is using the United Kingdom, USA, or Australia locales, JavaScriptCore returns the expected locale.

Reproduction steps:

* Open Language & Region in System Preferences
* Change the Region to the region under test
* Open a Safari web-page and the Web Inspector
* Run this statements in the Console:

[new Intl.DateTimeFormat("default").resolvedOptions().locale,
new Intl.DateTimeFormat().resolvedOptions().locale,
new Intl.DateTimeFormat().format(new Date())]

Current output:

// In the Australia region:
=> ["en-AU", "en-AU", "24/04/2019"]

// In United Kingdom
=> ["en-GB", "en-GB", "24/04/2019"]

// In United States
=> ["en-US", "en-US", "4/24/2019"]

// In New Zealand (this one shows the problem)
=> ["en-US", "en-US", "4/24/2019"]

Expected output for New Zealand:

["en-NZ", "en-NZ", "24/04/2019"]

JavaScriptCore does correctly format the output if the en-NZ locale is specified:

[new Intl.DateTimeFormat("en-NZ").resolvedOptions().locale,
new Intl.DateTimeFormat("en-NZ").format(new Date())]
=> ["en-NZ", "en-US", "24/04/2019"]

I would expect that the default locale returned by JavaScriptCore matches the system locale, especially where JavaScriptCore does support that locale like en-NZ. If en-NZ is not supported, then I would probably expect to default to en-AU, and failing that en-GB. Both of those locales are more similar to en-NZ than en-US is.

Tested in
Safari Technology Preview: Release 80 (Safari 12.2, WebKit 14608.1.16)
Safari: Version 12.1 (14607.1.40.1.4)

Other notes:

I tested this briefly in Chrome and Firefox for the NZ region. Chrome returns en-NZ as the default locale, Firefox has the same behaviour as Safari

[Alexey Proskuryakov]

I suspect that JavaScriptCore ends up using bundle localization for default locale, which actually feels correct - it's not great when browser UI and webpage content use different languages and formats. Safari happens to have "en", "en_AU" and "en_GB" localizations, but no "en_NZ".

> If en-NZ is not supported, then I would probably expect to default to en-AU, and failing that en-GB. Both of those locales are more similar to en-NZ than en-US is.

That's a good idea. Unlike the main issue reported here, such logic definitely wouldn't be in WebKit though, it would be in Foundation. WebKit relies on underlying system to resolve locales, so Foundation would need to decide that en_AU should be used instead of the default. Please feel welcome to file a bug for Apple to consider via https://bugreport.apple.com

[Daniel Compton]

Thanks for the feedback, it makes sense how this is happening. I've opened rdar://50280505 for the Foundation enhancement. Feel free to close this issue if there's no further actions to take available in WebKit.

[Daniel Compton]

Also, I forgot to mention that I really appreciated the full explanation of what is happening. Thanks!

[Alexey Proskuryakov]

Leaving open for the JSC folks to confirm whether they agree that this is expected behavior.

[Andy VanWagoner]

JSC looks up the default locale from its embedder (Foundation or WebCore), falling back to libicu's default locale, and ultimately to "en" if none of those others had a value.

Resolving to a "closest" default locale is not specified in the ECMA 402 spec, but I agree "en-US" isn't a great fit for "en-NZ".

I can't speak to where the logic ultimately would need to change (Foundation, WebCore, or elsewhere in Safari), but it's not currently in JSC.

Does `navigator.language` agree with `Intl.DateTimeFormat().resolvedOptions().locale`?

[Daniel Compton]

> Does `navigator.language` agree with `Intl.DateTimeFormat().resolvedOptions().locale`?

Yes, with macOS in the NZ Locale, Safari shows:

> [navigator.language, Intl.DateTimeFormat().resolvedOptions().locale]
< ["en-US", "en-US"]

[Andy VanWagoner]

(In reply to Daniel Compton from comment #6)
> > Does `navigator.language` agree with `Intl.DateTimeFormat().resolvedOptions().locale`?
> 
> Yes, with macOS in the NZ Locale, Safari shows:
> 
> > [navigator.language, Intl.DateTimeFormat().resolvedOptions().locale]
> < ["en-US", "en-US"]

Ok, good. Intl apis are behaving as expected, then.

[Ross Kirsling]

Closing as I'm seeing `new Intl.DateTimeFormat("en-NZ").resolvedOptions().locale` return "en-NZ" in STP 104 on Catalina.

Please reopen if there's still an issue here.

[Daniel Compton]

I think this is fixed, though there may be a regression in STP?

Running this on Safari 13.1, macOS 10.15.4 in NZ region:

[new Intl.DateTimeFormat("default").resolvedOptions().locale,
new Intl.DateTimeFormat().resolvedOptions().locale,
new Intl.DateTimeFormat().format(new Date()),
navigator.language]

=> ["en-AU", "en-AU", "15/04/2020", "en-au"] 

Running the same in STP Release 104 (Safari 13.2, WebKit 15610.1.8.3) returns:

=> ["en-US", "en-US", "4/15/2020", "en-us"]

[Alexey Proskuryakov]

Could you please file a new bug about this? I did't see the same problem with Russian, although I found a different regression, bug 210554.

In the new bug, please provide the output of "defaults read -g AppleLanguages; defaults read -g AppleLocale" on your machine.