(new Date()).toLocaleString() changed format

NEW
Unassigned

Status

()

defect
5 years ago
4 years ago

People

(Reporter: fry.kun, Unassigned)

Tracking

({regression, site-compat})

29 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

JS on my webpage runs (new Date()).toLocaleString();

"5/13/2014, 12:00:00 AM" is printed

"Tue 13 May 2014 12:00:00 AM PDT" should be printed, instead

from bash command line:
$ date +%c -d@1399964400
Tue 13 May 2014 12:00:00 AM PDT

Firefox does not have special locale settings, as far as I know. Older versions used to print the correct locale string


Using Fedora 20 kernel 3.14.3-200.fc20.x86_64, firefox-29.0-5.fc20.x86_64
Confirmed. Seems like the same issue as Bug 999003
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 999003
I disagree, this is a different problem (though likely related).
In this issue, the problem is that the system locale format is NOT used. Bug 999003 seems to have the opposite problem statement -- that system locale is used when it shouldn't be (?).

Also note that specifying the locale explicitly -- .toLocaleString('en-US') -- doesn't work around this bug.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Severity: critical → normal
Component: Untriaged → JavaScript Engine
OS: Linux → All
Product: Firefox → Core
Hardware: x86_64 → All
Yea, now Firefox returns the same result as Chrome, but not sure what's this format.
Status: UNCONFIRMED → NEW
Ever confirmed: true
interestingly, .toGMTString() kept the format
Probably the format changed when ECMA-402 Intl support was enabled in Firefox. You can tweak the output format through the `options` argument of the Date.prototype.toLocaleString() function. For example:
---
(new Date).toLocaleString("en-US", {weekday:"short", year: "numeric", month: "short", day: "numeric", hour: "numeric", minute:"numeric", second: "numeric", timeZoneName: "short", hour12: true})
---

should return a string similar to `"Thu, May 15, 2014, 10:38:15 AM PDT"`. 

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString
Luckily my app has not been affected since it uses to the Gecko-specific toLocaleFormat method. Anyways this change is a backward compatibility issue. Updated the doc:

https://developer.mozilla.org/en-US/Firefox/Releases/29/Site_Compatibility
Blocks: 1009795
Any further comment/action on this?

Does "browser locale" differe from "OS locale"?

Note: https://bugzilla.mozilla.org/show_bug.cgi?id=999003#c48
"We should use the document language, followed by the UI language, followed by the OS language. If we'd like to insert accept-lang, I'd put it last or second to last."
(In reply to Konstantin Svist from comment #7)
> Any further comment/action on this?
> 
> Does "browser locale" differe from "OS locale"?

I don't think we know what we want, exactly, just yet.  Unfortunately there are several different senses of "locale" in play in various parts of Firefox -- the locales sent by the Accept-Language header, the locales as claimed by the OS, the locale set by LANG, etc.  I don't know why we have more than one, to be honest.  And I don't know how we're going to meaningfully select among them.

More discussion needed, at least part of it in the bug you mention, maybe.

> Note: https://bugzilla.mozilla.org/show_bug.cgi?id=999003#c48
> "We should use the document language, followed by the UI language, followed
> by the OS language. If we'd like to insert accept-lang, I'd put it last or
> second to last."

Frankly, I find that logic pretty dubious at first appearance.  But I won't claim to be an expert on this stuff.
Actually, this bug is not even about selecting the right locale. More like, all locale defaults are already set to en-US. But the returned string is not using en-US locale for some reason!
I recently finally updated from FF28 and noticed this too. On a website that used to to show "Sunday, November 9, 2014" now simply shows "11/9/2014" which is driving me crazy.
Component: JavaScript Engine → JavaScript: Internationalization API
You need to log in before you can comment on or make changes to this bug.