Issue metadata
Sign in to add a comment
|
Intl.DateTimeFormat uses wrong default locale
Reported by
robertkn...@gmail.com,
May 9 2017
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30
Steps to reproduce the problem:
I am trying to format a date string using the current system locale, using the short version of the month name. The formatting changed in Chrome v58 and it looks like an issue with how the default locale is resolved when unspecified.
1. Set system language to your primary language (I tested on OS X 10.12.4 with English UK as my default language)
2. Evaluate `Intl.DateTimeFormat().resolvedOptions().locale`
3. Set system language to something different (I tested with French), then restart Chrome and repeat (2)
What is the expected behavior?
In Safari, Firefox and Chrome < 58, the locale reported in step (2) is "en-GB", where "en-GB" matches my current system locale.
What went wrong?
In Chrome v58 the locale value is "und". In step (3) however when my system locale is set to something other than the default, Chrome v58 reports the expected locale.
When the locale value is "und", this affects date formatting. For example:
```
new Date('2016-11-01').toLocaleString(undefined, { day: 'numeric', month: 'short', year: 'numeric' })
```
Returns "1 Nov 2016" (or similar) in Chrome <58 but "2016 M11 1" in Chrome v58.
Did this work before? Yes 57
Chrome version: 58.0.3029.96 Channel: stable
OS Version: OS X 10.12.4
Flash Version:
I found this while investigating an unexpected change in the formatting of timestamps in our app: https://github.com/hypothesis/client/issues/378#issuecomment-300241710
,
May 10 2017
Tested in chrome # 58.0.3029.96 and Canary #60.0.3094.0 on Mac 10.12.3 and able to reproduce the issue.It is observed that able to reproduce the issue in M-57 also.Please find the screen shots for your reference. Steps Followed: 1.Set system language to your primary language(EN-US) 2.Run the command in console `Intl.DateTimeFormat().resolvedOptions().locale`. 3.Change the system language to French and repeat(2) @Reporter: Could you please let me know if i have missed anything and if possible,Please conform and provide sample steps of the issue which would help us to triage the issue further. Thanks in Advance.
,
May 17 2017
Hello rbasuvula. The screenshot of M57 does not show the issue that I originally reported. My comment about the actual result I get in M58 after following the STR is: "In Chrome v58 the locale value is "und". In step (3) however when my system locale is set to something other than the default, Chrome v58 reports the expected locale." Related to this, I have since installed the dev channel build of Chrome (currently M60) and can confirm it is still happening there.
,
May 17 2017
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 17 2017
I'm seeing a similar issue here with Chrome 58.0.3029.110, however, it appears to be working correctly in Chrome Canary 60.0.3102.0. We've had a customer complain and we're using number.toLocaleString which also seems to be affected. -- Chrome 58.0.3029.110 -- Portuguese (Brazil) Intl.DateTimeFormat().resolvedOptions().locale "und" 5432.1.toLocaleString() "5,432.1" -- Chrome Canary 60.0.3102.0 (correct) -- Portuguese (Brazil) Intl.DateTimeFormat().resolvedOptions().locale "pt-BR" 5432.1.toLocaleString() "5.432,1" I'm not sure it's the same issue though.
,
May 18 2017
Thanks for your reply. Tested in chrome #58.0.3029.96, Stable #58.0.3029.110 and Canary #60.0.3102.0 on mac 10.12.3 and not able to reproduce the issue.Please find the screen shots for your reference. @Reporter:Could you please let me know if i have missed anything and if possible,Please create new profile without extensions and apps.Re-check once and let us know the observations and provide the screen cast of the issue which would help us to triage the issue further. Thanks in Advance.
,
May 18 2017
@rbasuvula - I am still seeing the original issue using the same build of Chrome (M58, same rev) as you and following the same steps, reproduced in a Guest Profile with no extensions or apps loaded. See attached screenshot. Like comment #5, I do not see the issue in Chrome Canary (M60). See second attached screenshot.
,
May 18 2017
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 19 2017
Could some one from Localization / Dev tools dev team please look in to this issue. Thank you!
,
May 19 2017
It's reproducible without DevTools, forwarded to V8 internalization..
,
May 23 2017
,
May 23 2017
,
May 24 2017
rbasuvula@, can you run bisect? Also, can you try Linux and Windows as well? On Linux, you can do: $ LANGUAGE=en-GB chrome $ LANGUAGE=fr chrome On Windows, you can add a command line flag '--lang=en-GB' or '--lang=fr' After that, assign it back to me. Thanks
,
May 24 2017
bisect range: 57.0.2987.98 - 58.0.3029.96 ( 454471 ). Bisected it: You are probably looking for a change made after 451118 (known good), but no later than 451132 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/b756297e51407c3b602c6d65746a8f18d835d71b..5959d07ba1e77b02c3c67698243fdf0f3ee186fc Has just one v8 roll: https://chromium.googlesource.com/chromium/src/+/282e0cb603 which brought in the following changes: https://chromium.googlesource.com/v8/v8/+log/dae37da8..16c2739b One of them is https://chromium.googlesource.com/v8/v8/+/3059138b2 [intl] Fall back on an invalid default locale to "und" This turned out to be too broad (if any of services is not supported in a given locale, the locale for *all* services is set to 'und'. (and due to the way ICU's availableLocale list is generated, some locales are incorrectly flagged as not supported). // Check that this is a valid default, otherwise fall back to "und" 157 for (let service in AVAILABLE_LOCALES) { 158 if (IS_UNDEFINED(getAvailableLocalesOf(service)[DEFAULT_ICU_LOCALE])) { 159 DEFAULT_ICU_LOCALE = "und"; 160 break; 161 } 162 } This was later changed to set the locale to 'und' per service (instead of across services), but that change is not merged to 58. This is rather serious. For 58 branch, we may as well just revert https://chromium.googlesource.com/v8/v8/+/3059138b2 However, there might not be any more 58 release.
,
May 24 2017
,
May 24 2017
60.0.3109.0 is fine, but 59.0.3071.60 is broken.
,
May 24 2017
,
May 24 2017
59.0.3071.x has https://chromium.googlesource.com/v8/v8/+/55f70d7c90559 . The code snippet in comment 14 is still there.
,
May 24 2017
https://chromium.googlesource.com/v8/v8/+/ec453452c : Version 5.9.211.28 has the same issue. Adam, how can I revert https://codereview.chromium.org/2646593002 for Chromium M59 or cherry-pick Dan's follow-up CL? In v8, which branch should I apply the revert?
,
May 24 2017
@jshin, can you link to the followup? We should be able to merge to 59.
,
May 24 2017
,
May 24 2017
Issue 698855 has been merged into this issue.
,
May 24 2017
,
May 24 2017
bug 698855 is a critical bug. Date format in File manager is broken in en-GB and pt-BR locales. We even need an emergency fix for M58.....
,
May 24 2017
> Is this https://bugs.chromium.org/p/v8/issues/detail?id=6288? Yes. Bernie, you told me that there will not be any more M58 release for Chrome OS, didn't you? When will Chrome OS stable be updated to M59/R59? Is it going to be early June? bug 698855 is rather serious for en-GB and pt-BR users. I wonder if there should be an emergency fix for them in 58.x.
,
May 24 2017
We should have 59 stable in two weeks (June 6th) by the schedule. We are not planning any further 58 builds short of an emergency, given the linked bug has been around since early March as a pri 2 it does not seem it had qualified as an emergency previously. If we did another spin of 58 the earliest it would be deployed is mid next week leaving little time before 59.
,
May 24 2017
Thank you for the reply, Bernie . Ok. fair enough (I wish bug 698855 had been brought to my attention sooner; we also have to review our QA process for non-en-US locales, I guess; I should have realized the implication of bug v8:6288 ). Let's fix it in M59.
,
May 24 2017
> @jshin, can you link to the followup? We should be able to merge to 59. As I wrote in bug v8:6288 , I have little idea as to how to make a change in v8 branch to use with Chrome M59 branch. An (automatic) cherry-pick of Dan's 2nd CL in v8:6288 wouldn't work due to file name changes, I'm afraid. Reverting Dan's 1st CL (February) in a branch would be simpler, wouldn't it? If you let me know which v8 branch to touch for Chrome M59 branch, I'll make a change.
,
May 27 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/1c171759ebb6e1a50ff0c5efcec9f6073b22e62a commit 1c171759ebb6e1a50ff0c5efcec9f6073b22e62a Author: Adam Klein <adamk@chromium.org> Date: Sat May 27 21:40:43 2017 Revert "[intl] Fall back on an invalid default locale to "und"" This reverts commit 3059138b20bb56918cce24003832442c0ad701fa. TBR=littledan@chromium.org Bug: v8:6288 , chromium:698855 , chromium:720030 Change-Id: If4feb06c80f1f8f49c06ea6aeaffc8f1a072bdea Reviewed-on: https://chromium-review.googlesource.com/517182 Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/branch-heads/5.9@{#63} Cr-Branched-From: fe9bb7e6e251159852770160cfb21dad3cf03523-refs/heads/5.9.211@{#1} Cr-Branched-From: 70ad23791a21c0dd7ecef8d4d8dd30ff6fc291f6-refs/heads/master@{#44591} [modify] https://crrev.com/1c171759ebb6e1a50ff0c5efcec9f6073b22e62a/src/js/i18n.js
,
May 31 2017
@jshin, is there anything we want to do for the M60 branch? Or is littledan's fix sufficient for now?
,
Jun 5 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, May 9 2017