1820375 - Date-type input elements formatted incorrectly when using Canadian locale (en-CA)

Status: RESOLVED DUPLICATE of bug 1818103

(Core :: Internationalization, defect)

Description

[Bugenes Relocare]

Overview:
When using the en-CA locale and viewing an HTML <input> element of type date or datetime-local, the date is formatted as MM/DD/YYYY which is least common for this locale. The more common format is YYYY-MM-DD (as it has been in previous versions of Firefox, and preferred by the Canadian government), or the slightly less common DD-MM-YYYY.

Build ID:
20230214051806

Additional Builds and Platforms:
The following tested on Linux with different Firefox versions downloaded from https://ftp.mozilla.org/pub/firefox/releases/[VERSION]/linux-x86_64/en-CA/

• Does NOT occur on: 90.0, 105.0, 106.0, 107.0, 108.0, 109.0, 109.0.1, 109.0b6, 109.0b8, 109.0b9 (Build ID: 20230105190654)
• DOES occur on: 110.0.1 (Build ID: 20230227191043), 111.0b8 (Build ID: 20230302185836), 112.0a1 (Build ID: 20230304095224) (Nightly)

Steps to consistently reproduce:

• Launch a new instance of Firefox with locale set to en-CA (Settings > General > Language > English (CA))
• Visit any web page that uses the HTML element <input type="date"> or <input type="datetime-local">, such as this MDN page.

Expected result:
The date should be formatted as YYYY-MM-DD

Actual result:
The date is formatted as MM/DD/YYYY

Additional Details:
This seems to be related to this CLDR issue, which also affects the method toLocaleDateString() of the Date class in JavaScript.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Hello, thanks for the bug report! One thing that might be helpful for us to get this bug in front of the right engineer for investigation would be if we can get a more narrow regression range for when this behavior changed. Would you be willing to try to narrow that down using the mozregression tool linked below? It will not impact your regular Firefox profile.
https://mozilla.github.io/mozregression/

Thanks!

Comment 3

[Bugenes Relocare]

Glad to be of some help!

Results from mozregression
Last good revision: 48181532b788f8b28d5a9ebe88028e585bf6e4ef
First bad revision: d722b25231b9e10755c0efc93a2df8891676213d
Pushlog HTML

---

Since this is my first time using mozregression, I'll just document the way I used the tool, as briefly as possible, in case I misused it somehow:

In the terminal I entered:
mozregression --good 109.0.1 --prefrences prefs.json --background-dl-policy keep --arg="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date"

I typed in good if the date format was correct (YYYY-MM-DD), and typed bad if it was incorrect.

prefs.json

{
    "intl.locale.requested": "en-CA",
    "intl.accept_languages": "en-CA",
    "intl.regional_prefs.use_os_locales": true
}

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Unfortunately, that didn't really narrow down the range. I suspect that's because of specifying 109.0.1 as the good build instead of 109. Can you try this command instead?

mozregression --good 109 --bad 110 --preferences prefs.json --background-dl-policy keep --arg="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date"

Comment 5

[Bugenes Relocare]

I did try having both good and bad options set to their appropriate Build IDs, then again to their appropriate release numbers, but this ended up giving me an error (detailed below) in both situations!

However, I did a bit of reading after your suggestion, and found this comment on a bug report that suggested using a wider range, so I did that:

mozregression --good 107 --bad 110 --preferences prefs.json --background-dl-policy keep --arg="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date"

Results from mozregression
Last good revision: 7a1faa41f831ac8c3e5e751bde276a6a1d3eff39
First bad revision: b12f89a6bbffe2c243b664c4a4f60cd8a7b1c65c
Pushlog HTML

Hopefully this is what we're looking for! If not, please read on below for my other tests.

---

If the above is incorrect, below are two other attempts that were made.

# 1
mozregression --good 109 --bad 110 --preferences prefs.json --background-dl-policy keep --arg="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date"

The <input type="date"> element did not show the proper date format, but after entering bad, the following error is printed, and the bisection ends:
ERROR: Build was expected to be good! The initial good/bad range seems incorrect.

# 2
mozregression --good 109.0 --bad 110.0 --preferences prefs.json --background-dl-policy keep --arg="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date"

Results from mozregression
Last good revision: 48181532b788f8b28d5a9ebe88028e585bf6e4ef
First bad revision: d722b25231b9e10755c0efc93a2df8891676213d
Pushlog HTML

Comment 6

[Ryan VanderMeulen [:RyanVM]]

(In reply to Bugenes Relocare from comment #5)

Results from mozregression
Last good revision: 7a1faa41f831ac8c3e5e751bde276a6a1d3eff39
First bad revision: b12f89a6bbffe2c243b664c4a4f60cd8a7b1c65c
Pushlog HTML

This is exactly what I was looking for, thanks! Andre, is this a dupe of bug 1818103?

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1792775

Comment 8

[André Bargull [:anba]]

Yes, this is a dup of bug 1818103.