New issue
Advanced search Search tips
Starred by 4 users

Issue metadata

Status: WontFix
Closed: Jan 27
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug

Sign in to add a comment

Issue 842524: Intl.DateTimeFormat().format() uses wrong format for hy locale

Reported by, May 13 2018

Issue description

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

Steps to reproduce the problem:
1. Consider command: `new Intl.DateTimeFormat('hy').format(new Date(2018, 10, 12))`
2. Run The command in Chrome
3. Run same command in Firefox

What is the expected behavior?
Firefox and Chrome both return DD.MM.YYYY format.

What went wrong?
Chrome returns 2018-11-12(YYYY-MM-DD) format, which is for me(Armenian) very unintuitive(I used to any combination of DMY).
According to [wikipedia]( ) It's more common to use DMY format(I know it's unofficial).
I did check both official [Prime minister]( and [President]( websites and both are using DD.MM.YYYY

So I think Chrome also should return DD.MM.YYYY

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 66.0.3359.139  Channel: stable
OS Version: OS X 10.13.4
Flash Version: 

I'm preparing a presentation which will also be localized for Armenia. But apparently I can not yet suggest to the Armenian audience to rely on Intl yet completely.

Relevant slide ->

Comment 1 by, May 13 2018

I thought this might be useful for Chromium team as well:

I have also run same test for the locales currently supported by Adblock Plus and seems like there are 21 locales(out of 81) that are showing inconsistent formatting across two Browsers as well, see the list below:

ast 2018-11-12
az 2018-11-12
be 2018-11-12
br 2018-11-12
bs 2018-11-12
cy 2018-11-12
dsb 11/12/2018
eu 2018-11-12
fy 11/12/2018
gl 2018-11-12
hsb 11/12/2018
hy 2018-11-12
is 2018-11-12
ka 2018-11-12
kab 11/12/2018
kk 2018-11-12
mk 2018-11-12
nn 2018-11-12
sq 2018-11-12
ur 2018-11-12
uz 2018-11-12

ast 12/11/2018
az 12.11.2018
be 12.11.2018
br 12/11/2018
bs 12.11.2018.
cy 12/11/2018
dsb 12.11.2018
eu 2018/11/12
fy 12-11-2018
gl 12/11/2018
hsb 12.11.2018
hy 12.11.2018
is 12.11.2018
ka 12.11.2018
kab 12/11/2018
kk 12.11.2018
mk 12.11.2018
nn 12.11.2018
sq 12.11.2018
ur 12/11/2018
uz 12/11/2018

Relevant Codepen:

Comment 2 by, May 14 2018

Labels: Needs-Triage-M66

Comment 3 by, May 14 2018

Labels: M-68 Triaged-ET FoundIn-68 Target-68 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on chrome reported version 66.0.3359.139 and latest stable 66.0.3359.170 using Mac 10.12.6, Windows-10 and Ubuntu 14.04, same issue is seen on latest chrome# 68.0.3430.0. Hence considering this issue as Non-Regression and marking it as untriaged.


Comment 4 by, May 23 2018

Components: -Blink>JavaScript Blink>JavaScript>Internationalization
Status: Available (was: Untriaged)

Comment 5 by, Jan 25

Status: Assigned (was: Available)
I believe this is due to the data trimming.

Comment 6 by, Jan 27

hy is included in so this locale should be supported.

Comment 7 by, Jan 27

Status: WontFix (was: Assigned)
All these locale are not in so it is not supported in Chrome.


Comment 8 by, Jan 28

Do I understand correctly that this function works reliably only in supported UI languages by Chrome, unless it's fixed ?

Wonder if that will also be true for other `Intl` function, like: `Intl.NumberFormat`, `Intl.ListFormat`?

Sign in to add a comment