The encoding problem seems to be fixed now in 51.0.2704.7 dev-m.

However, the Date string representation still does not respect my Chrome UI language. I'm not sure if that is an actual problem or by design, though.

Have you tried restarting Chrome after you changed its UI language?

Sure. My Chrome UI language was always set to English through numerous updates and reboots. Afaik a language change in Chrome's menus etc. does not take effect until Chrome is restarted anyway.

I just tried it again just to confirm. The problem also exists in the current stable version 50.0.2661.75 m.

What I find really strange is the way the Date is translated on a machine with German Windows UI language:

  Thu Apr 21 2016 19:16:54 GMT+0200 (Mitteleuropäische Sommerzeit)

The representation is the same whether Chrome's UI language is in English or German, i.e. the weekday is always in English and the timezone is always in German.

I also have a box with English Windows UI language and English Chrome UI language and the Date displays correctly:

  Thu Apr 21 2016 19:25:58 GMT+0200 (W. Europe Daylight Time)

If I change Chrome's UI language on that computer to German, the representation of the Date object is also unaffected and remains English.

So the language of the time zone always seems to follow the Windows UI language instead of Chrome's UI language, while the weekday and month are always in English.

The problem also exists with 52.0.2714.0 canary (64-bit).

I just had a look at the relevant Chromium source code and the ES6 spec.
Here are my observations:

1. Regarding the localization of Date().toString() the ES spec does not prescribe a specific format, other than that it should be in a "convenient, human-readable form". So according to this, a case could be made for localizing the weekday and month as well as the timezone.
Currently, the DateString is generated here [1], using the hard coded weekday and month names here [2]. It could be argued that Chrome should localize weekday and month, as there are quite a few websites that use Date().toString() to display a Date in a user friendly manner and users may expect a date representation to be properly localized.

2. There is however a problem with localizing weekdays and month names in that the ES spec requires that a Date object x can be roundtripped using Date.parse(x.toString()) [3], except for the milliseconds. While the current Date.parse() logic seems to ignore the name of the weekday, since the (numeric) day of the month is sufficient, there is a hardcoded list of (English) month names here [4] that are used to parse a date string returned from Date().toString(). This logic would no longer work if the month name was localized, while the week day could presumably be localized, as it is ignored when parsing the string.

3. The code in [1] also gets the time zone name as per my original bug report in the Windows UI language. It does so by calling LocalTimezone(...) on a DateCache object[5], which in turn calls base::OS::LocalTimezone(double time, TimezoneCache* cache)) [6], which (on Windows) creates a Win32Time object [7]. A Win32Time object during initialization calls the OS function GetTimeZoneInformation(...) here [8]. The GetTimeZoneInformation function [9] returns a pointer to a TIME_ZONE_INFORMATION [10] struct that contains the members StandardName and DaylightName. Accodring to [9] the time zone names are always localized to the current user's UI language (as Windows supports installing language packs so that different users can have different UI languages). Back in Chrome, the TimezoneCache InitializeIfNeeded function converts these time zone names to UTF8 and they are handed back to ToDateString [1] where they are used verbatim to construct the final date string with SNPrintF [11] that is then used by the JS runtime.
Now, I don't know if it would be sane for Chrome to localize the time zone name on its own instead of just asking Windows. But as with the weekday and month names, a user may expect such a date string to be localized. On the other hand I recognize that running Chrome with a different UI language than Windows may be kind of a freakish configuration. It does beg the question why Chrome lets me choose a different UI language than my Windows UI language, though.

4. I found it odd that internationalization isn't a factor in the whole pipeline of ToDateString [1], as far as Chrome is concerned. All the names (weekday, month, timezone) are either hard coded in English or they come straight from the OS. Given that the output of this function is often exposed to ordinary users, it stands to reason that its output should be localized.

Sorry if my reply is overly verbose, but I had a lot of fun rummaging through the relevant source code. :)


[1] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/builtins.cc&l=3017&cl=GROK&gsn=ToDateString
[2] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/builtins.cc&cl=GROK&l=2973&gsn=kShortWeekDays
[3] https://tc39.github.io/ecma262/#sec-date.parse
[4] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/dateparser.cc&cl=GROK&l=119
[5] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/builtins.cc&l=3031&cl=GROK&gsn=ToDateString
[6] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/date.h&l=96
[7] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/base/platform/platform-win32.cc&l=470
[8] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/base/platform/platform-win32.cc&l=123
[9] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724421(v=vs.85).aspx
[10] https://msdn.microsoft.com/en-us/library/windows/desktop/ms725481(v=vs.85).aspx
[11] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/builtins.cc&l=3043&cl=GROK&gsn=ToDateString

Thank you for providing more feedback. Adding requester "hablich@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for elaborate response.

Per comment #2, I'm dropping 'results in mojibake' from the summary. 


Note that Date has toLocaleString() as well as toString().  toLocaleString() does produce a localized date format according to Chrome's UI language. 

Arguably, we should not localize anything for toString(). Perhaps, we may as well just use ISO 8601 (e.g. 2016-05-09T14:35:46-0700 ) for toString() instead of hardcoding English month names and weekday names. 

Round-tripping between Date and toString() should work with that. 

For a localized format, we can steer web developers to use toLocaleString() or Intl.DateTimeFormat(). 

At minimum, this inconsistency (comment 4) should be fixed:

"So the language of the time zone always seems to follow the Windows UI language instead of Chrome's UI language, while the weekday and month are always in English." 

See also  bug v8:3547  

I have a CL to address this issue as well as others.