1622557 - Intl DateTimeFormat: specifying era option changes order of date elements

Status: NEW

(Core :: JavaScript: Internationalization API, defect, P3)

Description

[LouisAime]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

You can test on https://louis-de-fouquieres.pagesperso-orange.fr/milesian/UnicodeTester.html
On Console:
myOptions = { era : undefined };
myOptionsNarrow = { era : "narrow" };
testDate = new Date (2020,2,13,12);
testFormat2 = new Intl.DateTimeFormat ('fr-u-ca-buddhist', myOptions);
testFormat3 = new Intl.DateTimeFormat ('fr-u-ca-buddhist', myOptionsNarrow);
resol2 = testFormat2.resolvedOptions();
resol3 = testFormat3.resolvedOptions();
testFormat2.format(testDate);
testFormat3.format(testDate);

Actual results:

resol2 and resol3 have the same era field, but differ slightly in other fields.
testFormat2 -> "EB 2563-03-13"
testFormat3 -> "13/3/2563 EB"

Expected results:

Date should always been displayed in same order, i.e. 13/3/2563
Leaving the era option blank, or specifying the default value, should yield the same effect.

This problem is not seen on Firefox for Android

Comment 1

[LouisAime]

This bug is with buddhist calendar only.

Comment 2

[André Bargull [:anba]]

This looks like an ICU bug.

There's no good fit for the requested date/time fields in common/main/fr.xml:

<availableFormats>
	<dateFormatItem id="d">d</dateFormatItem>
	<dateFormatItem id="M">L</dateFormatItem>
	<dateFormatItem id="Md">d/M</dateFormatItem>
	<dateFormatItem id="MEd">E d/M</dateFormatItem>
	<dateFormatItem id="MMM">LLL</dateFormatItem>
	<dateFormatItem id="MMMd">d MMM</dateFormatItem>
	<dateFormatItem id="MMMEd">E d MMM</dateFormatItem>
	<dateFormatItem id="y">y G</dateFormatItem>
</availableFormats>

So the fallback to common/main/root.xml should be used:

<dateTimeFormats>
	<alias source="locale" path="../../calendar[@type='generic']/dateTimeFormats"/>
</dateTimeFormats>

Unless I'm misunderstanding the alias handling in CLDR, we should end up with this entry from common/main/fr.xml:

<dateFormatItem id="yyyyMd">d/M/y GGGGG</dateFormatItem>

But instead ICU selects this entry from common/main/root.xml:

<dateFormatItem id="yyyyMEd">GGGGG y-MM-dd, E</dateFormatItem>

Comment 3

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

The priority flag is not set for this bug.
:Waldo, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[LouisAime]

Basically, the problem lays either in the ICU (bad alias handling) or in CLDR (incomplete data for fr file), may be in both.
I propose to carry this post to Unicode's bug report platform.
Feel free to close this bug.

Comment 5

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 6

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 7

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 8

[Firefox Bug Husbandry Bot]

The severity of these bugs was changed, mistakenly, from normal to S3.

Because these bugs have a priority of --, indicating that they have not been previously triaged, these bugs should be changed to Severity of --.

Comment 9

[LouisAime]

(In reply to LouisAime from comment #0)
A new GitHub Pages site for testing:
https://louis-aime.github.io/calendrical-javascript/