Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 3607 date.toLocaleString, toLocaleDateString and toLocaleTimeString are not locale-dependent
Starred by 22 users Reported by bksen...@gmail.com, Oct 20, 2008 Back to list
Status: Fixed
Owner: cira@chromium.org
Closed: Dec 2012
Components:
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 28604


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)


 
JSLocaleDateTimeError.jpg
49.4 KB View Download
jsLocaleDateTime.htm
368 bytes View Download
Comment 1 by lafo...@chromium.org, Oct 21, 2008
Labels: -Area-Misc Area-BrowserBackend JavaScript
Status: Untriaged
Comment 2 by mal.chro...@gmail.com, Oct 23, 2008
Labels: -Area-BrowserBackend Area-WebKit Mstone-1.0 I18N
Status: Assigned
Comment 3 by feng@chromium.org, Oct 28, 2008
I haven't started it yet, fixing another security one first.
Comment 4 by feng@chromium.org, Oct 28, 2008
Status: Started
Comment 5 by feng@chromium.org, 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.

Comment 6 by feng@chromium.org, Oct 29, 2008
Status: Duplicate
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.
Comment 7 by js...@chromium.org, Dec 16, 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. 

Comment 8 by js...@chromium.org, Dec 16, 2008
I filed a new V8 bug (http://code.google.com/p/v8/issues/detail?id=180 ) on the 
issue. 



Comment 9 by js...@chromium.org, Feb 25, 2010
Issue 29779 has been merged into this issue.
Comment 10 by js...@chromium.org, Feb 25, 2010
Summary: date.toLocaleString, toLocaleDateString and toLocaleTimeString are not locale-dependent (was: NULL)
Comment 11 by js...@chromium.org, Feb 25, 2010
Labels: -Mstone-1.0
Status:
Comment 12 by js...@chromium.org, Feb 25, 2010
see also bug 19254

Comment 13 by karen@chromium.org, Mar 15, 2010
Labels: Mstone-X
Comment 15 by mieli...@gmail.com, 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)"

Comment 16 by lafo...@chromium.org, Mar 18, 2011
Labels: -I18N bulkmove Feature-I18N
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)
Comment 17 by js...@chromium.org, Jun 9, 2011
Status: WontFix
With bug 28604 being worked on, this is obsolete in a sense. Cloased it as WontFix. 

Comment 18 by Deleted ...@, Jul 29, 2012
Why WontFix all Browser can do it right, just Chrome not
Comment 19 by js...@chromium.org, Jul 30, 2012
Labels: -Area-WebKit
Owner: cira@chromium.org
Status: Assigned
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 ?  

Comment 20 by js...@chromium.org, Jul 30, 2012
Blockedon: chromium:28604
Comment 21 by tkent@chromium.org, Aug 5, 2012
Issue 140675 has been merged into this issue.
Comment 22 by tkent@chromium.org, Aug 5, 2012
Labels: WebKit-JavaScript
Comment 23 by cira@chromium.org, Dec 28, 2012
Status: Fixed
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.
Project Member Comment 24 by bugdroid1@chromium.org, Mar 11, 2013
Labels: -Feature-I18N -WebKit-JavaScript Cr-Content-JavaScript Cr-UI-I18N
Project Member Comment 25 by bugdroid1@chromium.org, Mar 20, 2013
Labels: -Cr-UI-I18N Cr-UI-Internationalization
Project Member Comment 26 by bugdroid1@chromium.org, Apr 6, 2013
Labels: Cr-Blink
Project Member Comment 27 by bugdroid1@chromium.org, Apr 6, 2013
Labels: -Cr-Content-JavaScript Cr-Blink-JavaScript
Comment 28 by xerc...@gmail.com, Dec 8, 2013
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