476419 - Date.toLocaleString()/Date.toLocaleFormat() don't respect selected locale on OS X

Status: REOPENED

(Core :: JavaScript: Internationalization API, defect, P3)

Description

[Wladimir Palant]

new Date().toLocaleString() always returns something like "Mon Feb 2 08:36:28 2009" on OS X. Reason is that strftime() function is used to format dates - which always seems to use "C" locale by default. Calling uselocale() before strftime() "fixes" the issue:

  uselocale(newlocale(LC_ALL_MASK, "de_DE", NULL));

But here of course you first need to figure out which locale is currently selected. From what I can tell, you get this one by calling CFLocaleGetIdentifier(CFLocaleCopyCurrent()). I am not sure what that will do if the user chose to create his own custom date format.

Comment 1

[Wladimir Palant]

Same issue has been reported in bug 432102 (incorrectly resolved as a duplicate) and bug 368838 comment 17/18 (related but number formatting is a very different thing).

Comment 2

[Alexander L. Slovesnik]

Looks like similar issue was reported as Bug 482549

Comment 4

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

This bug is a big problem for localized webapps on Mac OS X and completely breaks the XUL datetimepicker since the date format is always en-US (month/day/year instead of for instance in french day/month/year) and the months' names are always in english... Nominating for blocking1.9.2.

Comment 5

[Mark Banner (:standard8)]

This has been causing Thunderbird issues as well. The workaround I'm considering is using nsIScriptableDateFormat, as that actually ends up calling into the OS specific date formatting functions (in nsDateTimeFormatMac), rather than strftime().

That isn't any help for localised webapps though...

Comment 6

[Wladimir Palant]

Yes, nsIScriptableDateFormat (via nsDateTimeFormatMac) has been fixed in bug 360018. It also doesn't suffer from bug 508783 which is why I switched Adblock Plus to use it.

Comment 7

[Stefan Plewako [:stef]]

Today I have hit sth that seems related:

If I start Aurora(10) as usual¹ and test toLocaleString in error console² I get "Fri Nov 18 16:30:20 2011" - exactly as described in this bug.

But… if I launch firefox from terminal³ I get the localized form - "ptk 18 lis 16:28:42 2011". The form itself is ugly⁴ and this may be related to bug 296302 but at least it is correct and localized.


1. like double click on Aurora.app in finder
2. alert((new Date).toLocaleString())
3. ~$ /Applications/Aurora.app/Contents/MacOS/firefox
4. Safari outputs "18 listopada 2011 16:42:52 CET" which is better but not perfect

Comment 8

[Stefan Plewako [:stef]]

Another similar bug about toLocaleFormat: bug 409832

Comment 9

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

I think toLocaleString now works properly because we switched it to ICU's based Intl (ECMA 402).

to LocaleFormat is still a dirty-hack and we should try to get rid of it.

Comment 10

[André Bargull [:anba]]

toLocaleString() should now work as expected and toLocaleFormat() is also tracked in bug 409832, therefore marking as a dup of bug 409832.

Comment 11

[Stefan Plewako [:stef]]

`new Date().toLocaleString()` returns "4/11/2017, 10:50:33 AM" for me.

Comment 12

[Stefan Plewako [:stef]]

Just tested this and it seems to depend on the way I launch application.

Comment 13

[André Bargull [:anba]]

toLocaleFormat was removed in bug 818634.

Comment 14

[André Bargull [:anba]]

Re-opening because I didn't see comment #11.

Comment 15

[Josh Berry]

I develop the Tab Stash extension for Firefox, and I have received a bug report from a user which I think is actually this bug. The user has customized their date/time formats, and Firefox is not respecting these customizations when Tab Stash's JS code is calling Date.toLocaleString().

I was able to reproduce the issue on macOS 11.4 with Firefox 90.0—I changed my date/time settings so that dates are formatted as "YYYY-MM-DD", and yet new Date().toLocaleString() still returns "M/D/YYYY"-formatted dates.

Would appreciate if this could be addressed, because it does have user-visible impacts. Thanks!

Comment 16

[Yulia Startsev [:yulia] OOO until July 2026]

It looks like this issue is still occurring, but is not hardcoded to the american system. We appear to default to the locale (i.e. "de-DE") which has a hard coded time format without respecting the user system settings. On my machine (a German MacBook Pro), I get the following outcome:

new Date().toLocaleString()
"15/11/2023, 20:40:35" 

This looks correct for the German convention, and aligns with my OS settings.

Updating my settings to display "YYYY-MM-DD" instead, I would expect to see:

new Date().toLocaleString()
"2023-11-15, 20:40:35" 

However instead I see:

new Date().toLocaleString()
"15/11/2023, 20:40:35" 

This would align with the behavior users have reported. I'm not sure if this is the intended behavior: https://tc39.es/ecma262/#sec-date.prototype.tolocalestring -- Based on the spec, I would expect the host to respect the system settings.

Comment 17

[André Bargull [:anba]]

"15/11/2023, 20:40:35" looks more like the expected result for locales like en-GB instead of de-DE, because the date separator is /, whereas for German . should be used.

I think intl.regional_prefs.use_os_locales needs to be set to always use the OS preferences and ignore any locales from the (localised) Firefox installation: https://firefox-source-docs.mozilla.org/intl/locale.html#regional-preferences

Comment 18

[Yulia Startsev [:yulia] OOO until July 2026]

Thanks for the follow up -- In this case, perhaps this is working as expected?

Comment 19

[Brahma Dev]

Possibly related. Running the following new Date(1743623960000).toLocaleString(['en-ES']).
outputs "4/2/2025, 7:59:20 PM" in Firefox and "2/4/2025, 7:59:20 PM" in Firefox Developer.

Same goes for date input. I get Month first in Firefox and Date first in Firefox Developer.

The system locale is set to en-ES and the installer used for both was en-GB.

Tested on Linux and Mac OS.

Comment 20

[André Bargull [:anba]]

(In reply to Brahma Dev from comment #19)

Possibly related. Running the following new Date(1743623960000).toLocaleString(['en-ES']).
outputs "4/2/2025, 7:59:20 PM" in Firefox and "2/4/2025, 7:59:20 PM" in Firefox Developer.

That behaviour is unrelated. Firefox Developer includes bug 1954425, which updates to ICU 77 and CLDR 47. As part of that update, en-ES is now a new supported locale for date-time formatting. en-ES follows en-150 (150 is the region code for Europe), which puts day of the month first. Firefox release doesn't yet contain the ICU update and therefore en-ES falls back to en (which is actually en-US), so the month comes first. You can use new Intl.DateTimeFormat("en-ES").resolvedOptions().locale to return the actually resolved locale. It'll return en-ES in Firefox Developer, but en in Firefox 137.

Comment 21

[Nickolay_Ponomarev]

In an attempt to possibly clear things up:

1. This bug -- as described in comment 0 -- is long fixed per comments 9-10 and 13: the formatting is not fixed to the "C" locale, the implementation does not use strftime(), and Date.toLocaleFormat() is removed.
2. The current behavior seems to agree with the specifications, though I'm not 100% sure I'm reading the specs correctly.
3. OS System Settings (Language & Region) are not always honored, and it doesn't seem specific to macOS:
   1. Firefox/Gecko ignore the system settings if the system language doesn't match the Firefox's language (the one you pick when downloading, I believe) UNLESS intl.regional_prefs.use_os_locales (aka "Use your operating system settings for “...” to format dates, times, numbers, and measurements.") is set to true. (docs / code?), which makes sense for chrome (for the reasons given in the docs), but not so much for content.
   2. Any customizations of the regional date and number formats are not supported. This seems to be a spec issue: Region Override Support #370, Allow for implementations to retrieve settings from host environment #109. See also bug 1575877
   3. The locale may be spoofed to combat fingerprinting; by default tracking protection does this to some sites, but it's possible to configure advanced protections, up to the nuclear option of privacy.spoof_english = 2. code can be traced from here

Up-to-date spec links:

• ECMA-262 delegates to ECMA-402 (Intl), when available: https://tc39.es/ecma262/#sec-date.prototype.tolocalestring
• ECMA-402: https://tc39.es/ecma402/#sup-date.prototype.tolocalestring