New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 848618 link

Starred by 3 users

Issue metadata

Status: ExternalDependency
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Feature



Sign in to add a comment

ja-JP-u-ca-japanese locale does not include Heisei era

Reported by kenta.ic...@nijibox.co.jp, Jun 1 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36

Steps to reproduce the problem:
1. run 
```
 new Intl.DateTimeFormat('ja-JP-u-ca-japanese', {year: 'numeric'}).format(new Date(2018, 1, 1))
```
or
```
(new Date(2018, 1, 1)).toLocaleDateString('ja-JP-u-ca-japanese')
```
in console

What is the expected behavior?
result:
chrome 66-> 平成30年
chrome 67-> 30年

What went wrong?
Does this change is intended to?

Did this work before? Yes 66

Chrome version: 67.0.3396.62  Channel: stable
OS Version: OS X 10.13.3
Flash Version:
 

Comment 1 by ajha@chromium.org, Jun 1 2018

Labels: Needs-Bisect Needs-Triage-M67
Cc: jungshik@google.com js...@chromium.org
jshin@, may be WAI? 
Similar  bug  848162 .

Comment 3 by tkent@chromium.org, Jun 1 2018

Components: -Blink Blink>JavaScript>Internationalization
FYI.
Firefox and Safari don't add "平成" for them.
Adding { era:"long" } shows "平成".

Cc: phanindra.mandapaka@chromium.org
Labels: -Needs-Bisect ReleaseBlock-Stable Triaged-ET RegressedIn-67 M-67 Target-67 FoundIn-67 Target-68 FoundIn-69 Target-69 hasbisect FoundIn-68 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce issue on reported chrome version 67.0.3396.62 & on latest chrome 69.0.3446.0 using Mac 10.13.3,Windows 10 and Ubuntu 17.10 . Hence providing bisect information below.

Bisect Info:
================
Good build: 67.0.3396.8
Bad build: 67.0.3396.10

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/67.0.3396.8..67.0.3396.10?pretty=fuller&n=10000

@js...@chromium.org/jungshik@google.com:Could anyone please help us in identifying the correct suspect for this issue as we are unable to find the suspect from the above change log.

Thanks!

Comment 5 by js...@chromium.org, Jun 1 2018

Cc: -jungshik@google.com -js...@chromium.org littledan@chromium.org
Labels: -Pri-2 -M-67 -Target-67 -Target-68 Pri-3
Owner: js...@chromium.org
Status: ExternalDependency (was: Untriaged)
This is due to  https://chromium-review.googlesource.com/1006915 .  It makes v8-compliant to the spec, but OTOH, it makes the result of this case less desirable. 

There's an spec bug to change the spec to make this and others work better. 

I'll add this example to the spec bug. 

Dan:  do you remember the spec bug on this issue (honoring Unicode extension such as 'ca-japanese' when picking the best match pattern out of 'skeleton')?  If you remember, please add this example to that. I'll look for it as well and try to add this to the bug. 

Comment 6 by js...@chromium.org, Jun 3 2018

Labels: -ReleaseBlock-Stable -Type-Bug-Regression -Needs-Triage-M67 Type-Feature

Sign in to add a comment