My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 3607: date.toLocaleString, toLocaleDateString and toLocaleTimeString are not locale-dependent
21 people starred this issue and may be notified of changes. Back to list
 
Reported by bksen...@gmail.com, Oct 20, 2008
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)


jsLocaleDateTime.htm
368 bytes   View   Download
JSLocaleDateTimeError.jpg
49.4 KB   View   Download
Oct 21, 2008
#1 lafo...@chromium.org
(No comment was entered for this change.)
Status: Untriaged
Labels: -Area-Misc Area-BrowserBackend JavaScript
Oct 23, 2008
#2 mal.chromium@gmail.com
(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
#3 f...@chromium.org
I haven't started it yet, fixing another security one first.
Oct 28, 2008
#4 f...@chromium.org
(No comment was entered for this change.)
Status: Started
Oct 29, 2008
#5 f...@chromium.org
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
#6 f...@chromium.org
I created a bug entry in V8:

https://code.google.com/p/v8/issues/detail?id=135

Close this one, and track it in V8.
Status: Duplicate
Dec 15, 2008
#7 jshin@chromium.org
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
#8 jshin@chromium.org
I filed a new V8 bug (https://code.google.com/p/v8/issues/detail?id=180 ) on the 
issue. 



Feb 25, 2010
#9 jshin@chromium.org
 Issue 29779  has been merged into this issue.
Feb 25, 2010
#10 jshin@chromium.org
(No comment was entered for this change.)
Summary: date.toLocaleString, toLocaleDateString and toLocaleTimeString are not locale-dependent
Feb 25, 2010
#11 jshin@chromium.org
(No comment was entered for this change.)
Status:
Labels: -Mstone-1.0
Feb 25, 2010
#12 jshin@chromium.org
see also bug 19254

Mar 15, 2010
#13 ka...@chromium.org
(No comment was entered for this change.)
Labels: Mstone-X
Feb 26, 2011
#15 mieli...@gmail.com
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
#16 lafo...@chromium.org
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 &gt; Regional and Language Options &gt; 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
#17 jshin@chromium.org
With  bug 28604  being worked on, this is obsolete in a sense. Cloased it as WontFix. 

Status: WontFix
Jul 29, 2012
#18 i...@shabab-alirschad.de
Why WontFix all Browser can do it right, just Chrome not
Jul 30, 2012
#19 jshin@chromium.org
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 https://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
#20 jshin@chromium.org
(No comment was entered for this change.)
Blockedon: chromium:28604
Aug 4, 2012
#21 tkent@chromium.org
 Issue 140675  has been merged into this issue.
Aug 4, 2012
#22 tkent@chromium.org
(No comment was entered for this change.)
Labels: WebKit-JavaScript
Dec 27, 2012
#23 c...@chromium.org
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
#24 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Feature-I18N -WebKit-JavaScript Cr-Content-JavaScript Cr-UI-I18N
Mar 20, 2013
#25 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-UI-I18N Cr-UI-Internationalization
Apr 5, 2013
#26 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: Cr-Blink
Apr 5, 2013
#27 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content-JavaScript Cr-Blink-JavaScript
Dec 8, 2013
#28 xerces9@gmail.com
Does not look fixed.
Just tested with v31 on Windows 8.1 Pro.

d = new Date(1292539800000);
document.write(d.toLocaleString());

prints: 12/16/2010 11:50:00 PM

My locale is Slovenian and the above appears to be American.

On the other hand
document.write(d.toString());

Prints: Thu Dec 16 2010 23:50:00 GMT+0100 (Central Europe Standard Time)
which is more correct. It show time in 24 hour format and the date part is the same as with other browsers.

For comparison, IE11 prints:
 - ‎16‎.‎12‎.‎2010‎ ‎23‎:‎50‎:‎00 
 - Thu Dec 16 2010 23:50:00 GMT+0100 (Central Europe Standard Time) 

Firefox 25:
 - 16. december 2010 23:50:00
 - Thu Dec 16 2010 23:50:00 GMT+0100 (Central Europe Standard Time) 
Sign in to add a comment

Powered by Google Project Hosting