1681357 - [ja] Word order of date/time is broken in ja build on Windows10 Japanese languages

Status: RESOLVED FIXED

(Core :: Internationalization: Localization, defect)

Description

[Alice0775 White]

[Tracking Requested - why for this release]: Word order of date/time is broken in ja build

Windows10 Japanese language.

Steps to reproduce:

1. Start Nightly85 ja build
2. Open Library > Import and Backup > Restore

Steps to reproduce:

1. Start Nightly85 ja build
2. Open any page (e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions )
3. Ctrl+I Page Info
4. See Modified: row

Actual Results:
Nightly85.0a1(Buildid 20201208094500): 水曜日, 09 12月 2020 02:54:10

Expected Results:
Firefox83.0: 2020年12月9日 2:53:15

Regression window:
(though, the good build renders garbled characters, see Bug 1681251)
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=eeee2b548e51eaad256f018fadaf1cc10e55c479&tochange=1a164819adefcdb42bdba8a24976b62ee8d03c80

Comment 1

[Alice0775 White]

Attachment: screenshot, Windows10 language settings

Comment 2

[Alice0775 White]

Attachment: screenshot: Firefox83 vs Nightly85.a1(20201208142416)

Comment 3

[Alice0775 White]

Evaluate the following js in Browser console

(new Services.intl.DateTimeFormat(undefined, {
    dateStyle: "long",
    timeStyle: "long",
  })).format(new Date("2020-12-08 21:00:05"));

Latest Nightly ja build returns: "火曜日, 08 12月 2020 21:00:05"
Firefox83.0 ja build returns "2020年12月8日 21:00:05"

Comment 4

[Geoff Lankow (:darktrojan)]

The same thing is happening in English. (I'm testing in Thunderbird, but it will be the same.)

What was "8 December 2020, 21:00:05 GMT+13" is now "2020 December 8 21:00:05 GMT+13".

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

The regression is caused by the change to how we handle undefined as a locale value.

Before bug 1635561, we would run the argument via a helper function that would populate it from regionalPrefsLocales. Now, we pass the undefined through expecting the DefaultLocale in JS Context to pick it up (DefaultLocale is also set to regionalPrefsLocales).

The issue is that in case of DateTimeFormat, when used with dateStyle/timeStyle we first call OsPreferences asking for the best pattern for the style. And we pass the locale based on the argument passed to the constructor.

In case the argument is undefined, we negotiate it against supportedLocalesOf, still get nothing, and then call:

osPrefs.getDateTimePattern(
  osPrefs.dateTimeFormatStyleLong,
  osPrefs.dateTimeFormatStyleLong,
  undefined
);

which returns "y MMMM d h:mm:ss a z".

Two ways to fix it that I can see are:

1. Fix OSPreferences to use regionalPrefsLocales if the locales argument is empty
2. Fix the MozIntl to do:

       class MozDateTimeFormat extends DateTimeFormat {
-        constructor(locales, options, ...args) {
+        constructor(locales = Services.locale.regionalPrefsLocales, options, ...args) {
           let resolvedLocales = DateTimeFormat.supportedLocalesOf(locales);

The former feels broader, but the latter is easier. Your call Dan.

Comment 6

[Dan Minor [:dminor]]

Thanks for investigating!

Comment 7

[Dan Minor [:dminor]]

Try push for the OSPreferences fix: https://treeherder.mozilla.org/jobs?repo=try&revision=365d1914960b81cb9911cb0fa6fbf68c50520614

Comment 8

[Dan Minor [:dminor]]

Attachment: Bug 1681357 - Use regional prefs locale if locale is not specified in GetDateTimePattern; r=zbraniecki!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/916ecdd8cf9a
Use regional prefs locale if locale is not specified in GetDateTimePattern; r=zbraniecki

Comment 10

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/916ecdd8cf9a

Comment 11

[Intermittent Failures Robot]

32 failures in 813 pushes (0.039 failures/push) were associated with this bug yesterday.

Repository breakdown:

• comm-central: 32

Platform breakdown:

• windows7-32: 7
• linux64: 8
• windows10-64: 7
• linux64-shippable: 4
• windows10-64-shippable: 3
• windows7-32-shippable: 3

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1681357&startday=2020-12-09&endday=2020-12-09&tree=all

Comment 12

[Intermittent Failures Robot]

32 failures in 4060 pushes (0.008 failures/push) were associated with this bug in the last 7 days.

This is the #34 most frequent failure this week.

** This failure happened more than 30 times this week! Resolving this bug is a high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 2 weeks, the affected test(s) may be disabled. **

Repository breakdown:

• comm-central: 32

Platform breakdown:

• windows7-32: 7
• linux64: 8
• windows10-64: 7
• linux64-shippable: 4
• windows10-64-shippable: 3
• windows7-32-shippable: 3

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1681357&startday=2020-12-07&endday=2020-12-13&tree=all