Closed Bug 1373885 Opened 7 years ago Closed 7 years ago

OS locale not respected for datetime formatting (regression)

Categories

(Core :: Internationalization, defect)

55 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox54 --- unaffected
firefox55 --- affected
firefox56 --- affected

People

(Reporter: takatomatsuki, Unassigned)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170615063713

Steps to reproduce:

Intl.DateTimeFormat({}).format(new Date());


Actual results:

Firefox 55 beta 1 and beta 2 return "6/17/2017"


Expected results:

"17/06/2017" should have been returned, as in Firefox 54 beta and earlier
Component: Untriaged → JavaScript: Internationalization API
Product: Firefox → Core
Regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b1c8b28b9fa2a8424db940d4b657eb59b3f01ff3&tochange=b45d664c0a7b10d6a54ceae884f2f8956f10bbec

Culprit: Bug 1346674

Is this an expected behaviour? If so, I'll post a site compatibility note.
Blocks: 1346674
Has Regression Range: --- → yes
Component: JavaScript: Internationalization API → Internationalization
Flags: needinfo?(gandalf)
Status: UNCONFIRMED → NEW
Ever confirmed: true
According to bug 1346674 comment 17 this change was intentional - date formatting is based on Firefox locale by default, not no OS locale any more.
These methods have the same issue:

// Previously 2017-06-17, now 6/17/2017 on macOS
(new Date()).toLocaleString();
(new Date()).toLocaleDateString();

Looks like my own web app is also affected :/
(In reply to Wladimir Palant from comment #2)
> According to bug 1346674 comment 17 this change was intentional - date
> formatting is based on Firefox locale by default, not no OS locale any more.

I hope it isn't intentional. Using the OS-set locale was a good reliable feature of Firefox. Forcing a Firefox-install defined locale is a step backwards.
I think the change is okay and makes sense. Firefox is literally an independent browser, should rely on the platform as little as possible. I was a bit confused because my macOS uses the en-CA locale while Firefox instances are en-GB or en-US, but only a limited number of macOS and Linux users will be affected as per Bug 1346674 Comment 1. To avoid such uncertainty, web developers can specify a locale for the Intl API if needed. I'm closing the bug as WONTFIX as per Bug 1346674 Comment 17 and writing a site compatibility note.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
For those who use English but not en-US or en-GB, what options do we have for having Firefox use our locale in 55 onwards?
This is an intentional change (see bug 1366134 for background and discussion about the spectrum of options).

> For those who use English but not en-US or en-GB, what options do we have for having Firefox use our locale in 55 onwards?

If you use English OS and English Firefox, then Firefox should pick up your regional preferences including date/time patterns.
If you use non-English OS and English Firefox, then you have to select from one of the available regional versions of Firefox.
Flags: needinfo?(gandalf)
> If you use English OS and English Firefox, then Firefox should pick up your regional preferences including date/time patterns.

It's not though, that's the problem. My OS is set to en-AU but Firefox is using en-US date/time formatting.
(In reply to Alex from comment #8)
> It's not though, that's the problem. My OS is set to en-AU but Firefox is
> using en-US date/time formatting.

Oh, cool. That's a regular bug then I guess :)

Since this bug is WONTFIXED and about intended behavior - would you mind opening a new bug and posting:
 - your OS
 - your OS's locale
 - your Firefox locale
 - an example of where the date is not picked up from the OS?

I'll check it against my test setup. Thank you!
I've started bug 1376265 as that's the issue I was trying to describe with this bug
Ok, so basically - there are two "modes" in which we operate - content (for web content) and chrome (for Firefox UI).

For content we do not support looking into OS Regional Preferences as per ECMA402 spec (and neither does any other browser). We just take the browser locale and use it. Thus wontfix.

For chrome (webextensions, Firefox UI etc.) we do look into OS preferences when the language matches between the browser and the OS.
You need to log in before you can comment on or make changes to this bug.