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.

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).

Looks like similar issue was reported as Bug 482549

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.

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...

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.

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

Another similar bug about toLocaleFormat: bug 409832

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.

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

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

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

toLocaleFormat was removed in bug 818634.

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