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

REOPENED
Unassigned

Status

()

REOPENED
10 years ago
9 months ago

People

(Reporter: gaubugzilla, Unassigned)

Tracking

Trunk
All
Mac OS X
Points:
---
Bug Flags:
blocking1.9.2 -
wanted1.9.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
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
Duplicate of this bug: 511052
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.
Flags: blocking1.9.2?

Updated

9 years ago
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: 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...
(Reporter)

Comment 6

8 years ago
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.
No longer blocks: 467520
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

Updated

7 years ago
Hardware: x86 → All
(Assignee)

Updated

4 years ago
Assignee: general → nobody
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.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 409832
`new Date().toLocaleString()` returns "4/11/2017, 10:50:33 AM" for me.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Just tested this and it seems to depend on the way I launch application.
toLocaleFormat was removed in bug 818634.
Status: REOPENED → RESOLVED
Last Resolved: a year ago9 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 818634
Re-opening because I didn't see comment #11.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
You need to log in before you can comment on or make changes to this bug.