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

REOPENED
Unassigned

Status

()

defect
REOPENED
10 years ago
2 years ago

People

(Reporter: gaubugzilla, Unassigned)

Tracking

Trunk
All
macOS
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

10 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

9 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: abp
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
Hardware: x86 → All
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: 2 years 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: 2 years ago2 years 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.