Issue 3607: | date.toLocaleString, toLocaleDateString and toLocaleTimeString are not locale-dependent | |
19 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Chrome Version : 0.3.154.3 (Official Build 3339) URLs (if applicable) : see attached HTML Other browsers tested: Chrome: FAIL Safari 3: 50% pass Opera 9: OK Firefox 3: OK IE 7: OK What steps will reproduce the problem? 1. Run the attached HTML test case, which basically runs: new Date().toLocaleDateString() new Date().toLocaleTimeString() What is the expected result? On Windows, output locale date and time strings formatted according to Control Panel > Regional and Language Options > Regional Options What happens instead? Chrome displays a 3-character string for day-of-week and displays 24-hour format for the time. At least, Safari gets the date display correct, although it also incorrectly displays 24-hour time. (See attached screenshot)
Oct 23, 2008
(No comment was entered for this change.)
Status:
Assigned
Owner: f...@chromium.org Labels: -Area-BrowserBackend Area-WebKit Mstone-1.0 I18N
Oct 28, 2008
I haven't started it yet, fixing another security one first.
Oct 28, 2008
(No comment was entered for this change.)
Status:
Started
Oct 29, 2008
I made a fix in V8 r645, but it only fixes the surface that brings Chrome close to Safari on Windows. As Ivan pointed out in review, we need someone who are familiar with Date and localization to make it work properly in all cases. Here is what Ivan said: LGTMForNow I am OK with this change for "Mstone-1.0" only to make it look more like Safari on Windows: It appears that Safari 3.1.2 on Windows does not honor the local machine setting for the Date formatting. Safari 3.1.2 on the Mac does change the output based on the system preference. We should mark the fact that this is a quick hack in the bug and assign the bug to somebody knowledgeable about date formatting to fix the real "I18N" issue.
Owner:
---
Oct 29, 2008
I created a bug entry in V8: http://code.google.com/p/v8/issues/detail?id=135 Close this one, and track it in V8.
Status:
Duplicate
Dec 15, 2008
I added a comment to V8 bug 135 , but I can't add myself to that bug and can't track its progress. I'll talk to Feng offline about the issue.
Dec 16, 2008
I filed a new V8 bug (http://code.google.com/p/v8/issues/detail?id=180 ) on the issue.
Feb 25, 2010
Issue 29779 has been merged into this issue.
Feb 25, 2010
(No comment was entered for this change.)
Summary:
date.toLocaleString, toLocaleDateString and toLocaleTimeString are not locale-dependent
Feb 25, 2010
(No comment was entered for this change.)
Status:
Labels: -Mstone-1.0
Feb 25, 2010
see also bug 19254
Mar 15, 2010
(No comment was entered for this change.)
Labels:
Mstone-X
Jan 17, 2011
http://code.google.com/p/chromium/issues/detail?id=69884 potentially related.
Feb 26, 2011
Chrome 11.0.672.2 dev/Win7, the results for toLocaleString is inconsistent: toLocaleDateString: "Saturday, February 26, 2011" toLocaleTimeString: "22:26:19" toLocaleString: "Sat Feb 26 2011 22:26:19 GMT+0100 (Central European Standard Time)" toString: "Sat Feb 26 2011 22:26:19 GMT+0100 (Central European Standard Time)"
Mar 18, 2011
Chrome Version : 0.3.154.3 (Official Build 3339) URLs (if applicable) : see attached HTML <b>Other browsers tested:</b> Chrome: FAIL Safari 3: 50% pass Opera 9: OK Firefox 3: OK IE 7: OK <b>What steps will reproduce the problem?</b> 1. Run the attached HTML test case, which basically runs: new Date().toLocaleDateString() new Date().toLocaleTimeString() <b>What is the expected result?</b> On Windows, output locale date and time strings formatted according to Control Panel > Regional and Language Options > Regional Options <b>What happens instead?</b> Chrome displays a 3-character string for day-of-week and displays 24-hour format for the time. At least, Safari gets the date display correct, although it also incorrectly displays 24-hour time. (See attached screenshot)
Labels:
-I18N bulkmove Feature-I18N
Jun 9, 2011
With bug 28604 being worked on, this is obsolete in a sense. Cloased it as WontFix.
Status:
WontFix
Jul 29, 2012
Why WontFix all Browser can do it right, just Chrome not
Jul 30, 2012
There's a now a proposal to implement toLocale* in terms of EcmaScript I18n API. See http://norbertlindenberg.com/2012/06/ecmascript-internationalization-api/index.html and http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts and http://code.google.com/p/v8-i18n @cira, should we file this against v8-i18n or v8 ?
Status:
Assigned
Owner: c...@chromium.org Labels: -Area-WebKit
Jul 30, 2012
(No comment was entered for this change.)
Blockedon:
chromium:28604
Aug 4, 2012
Issue 140675 has been merged into this issue.
Aug 4, 2012
(No comment was entered for this change.)
Labels:
WebKit-JavaScript
Dec 27, 2012
v8-i18n library overrides v8 methods now and outputs locale appropriate time/date/number. It doesn't check user settings on Windows, it uses whatever CLDR data we have for the given default locale.
Status:
Fixed
Mar 10, 2013
(No comment was entered for this change.)
Labels:
-Feature-I18N -WebKit-JavaScript Cr-Content-JavaScript Cr-UI-I18N
Mar 20, 2013
(No comment was entered for this change.)
Labels:
-Cr-UI-I18N Cr-UI-Internationalization
Apr 5, 2013
(No comment was entered for this change.)
Labels:
Cr-Blink
Apr 5, 2013
(No comment was entered for this change.)
Labels:
-Cr-Content-JavaScript Cr-Blink-JavaScript
|
||||||||||
► Sign in to add a comment |
Labels: -Area-Misc Area-BrowserBackend JavaScript