New issue
Advanced search Search tips

Issue 809924 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Date.toLocaleDateString('ar-DZ') is bugged

Reported by jpaarhu...@gmail.com, Feb 7 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
1. In the console execute: "new Date().toLocaleDateString("ar-DZ")"
2. It displays "72018/2/"

What is the expected behavior?
expected to see a valid date format like 2018/2/7

What went wrong?
Got: "72018/2/"

Did this work before? N/A 

Chrome version: 63.0.3239.132  Channel: stable
OS Version: 10.0
Flash Version:
 
Labels: Needs-Triage-M63

Comment 2 by e...@chromium.org, Feb 8 2018

Components: -Blink Blink>JavaScript>Internationalization
To add, it goes for all ar-* language codes
Cc: susan.boorgula@chromium.org
Labels: Triaged-ET M-66 FoundIn-66 Target-66 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
jpaarhuis7@ Thanks for the issue.

Tested this issue Windows 10, Ubuntu 14.04 and Mac OS 10.12.6 on the latest Canary 66.0.3350.0 and Stable 64.0.3282.168 and able to reproduce the issue.

On executing the given code in Console, can see the wrong date format.

Note : Till 61.0.3160.0 chrome version, can see some characters on Console on executing the code.
From 61.0.3161.0 build on wards, can see the wrong date format.
Attached are the screen shots for reference.

This is a Non-Regression issue as the expected date format is not observed from M60 Chrome builds. 
Hence marking this as Untriaged for further updates from Dev.

Thanks..
809924_bad.PNG
18.1 KB View Download
809924_buggy.PNG
17.8 KB View Download
Status: Available (was: Untriaged)

Comment 6 by js...@chromium.org, Apr 10 2018

Labels: -M-66 -Needs-Triage-M63 -Target-66
Owner: js...@chromium.org
Status: Assigned (was: Available)
Thank you for the report. Will not be fixed in M66. 

new Date().toLocaleString("ar")
"١٠‏/٤‏/٢٠١٨ ٣:١٣:١٨ م"
new Date().toLocaleString("ar-EG")
"١٠‏/٤‏/٢٠١٨ ٣:١٣:٢٢ م"
new Date().toLocaleString("ar-SD")
"١٠‏/٤‏/٢٠١٨ ٣:١٣:٢٧ م"
new Date().toLocaleString("ar-DZ")
"10‏/4‏/2018 3:13:31 م"
new Date().toLocaleTimeString("ar-DZ")
"3:14:03 م"
new Date().toLocaleDateString("ar-DZ")
"10‏/4‏/2018

Comment 7 by js...@chromium.org, Apr 17 2018

In ICU, ar_DZ does not have many patterns for date-time format. Most of patterns are inherited from ar locale.  ar locale uses 'arabic digit' and has some format control characters embedded in the pattern. OTOH, ar-DZ uses 'latin/ascii digit'. So, BiDi formatting characters can break formatting. 

For instance, yMd has this in "ar" and is inherited by ar-DZ.

yMd{"d<U+200F>/M<U+200F>/y"}

U+200F is R-to-L mark. 

There are other Arabic locales suffering from this issue  (ar-LB, ar-MA, etc). 

Comment 8 by js...@chromium.org, Apr 17 2018

Status: WontFix (was: Assigned)
Actually, this is almost WAI.  

See https://unicode.org/cldr/utility/bidi.jsp?a=04%E2%80%8F%2F02%E2%80%8F%2F1970&p=RTL   

In an RTL UI (where the paragraph direction is RTL), the above should be rendered correctly as

1970/02/04 . 


Sign in to add a comment