Treat islamic-rgsa as an unknown calendar identifier
Categories
(Core :: JavaScript: Internationalization API, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox152 | --- | fixed |
People
(Reporter: hsivonen, Assigned: anba)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
The islamic-rgsa identifier for Saudi Arabia sighting was added to CLDR on Oracle's request as part of the process of adopting (a subset of) Joda-Time into the Java standard library. OpenJDK (and most derivatives?) ended up shipping only islamic-umalqura (civil-use Saudi Arabia-official astronomical simulation) and, in the docs, acknowledging the possibility of past-data-only calendars, which clearly suggests viewing islamic-rgsa as such in contrast to islamic-umalqura.
None of CLDR, ICU4C, ICU4J, or ICU4X has past sighting data, but when islamic-rgsa has been requested, ICU4C has returned a calendar instance for an undocumented simulation, which has been accidentally exposed to the Web due to failure to investigate the ICU4C internals properly on this point to realize that there is no distinct islamic-rgsa back end in ICU4C.
Per the December 2025 TG2 meeting, we should treat islamic-rgsa like we treat unknown calendar identifiers. That is, -u-ca-islamic-rgsa and -u-ca-example should result in the same Web-visible behavior.
(An HTTP Archive search indicated that islamic-rgsa is not used on the Web.)
| Assignee | ||
Comment 1•7 months ago
•
|
||
If islamic-rgsa gets completely ignored for Intl.DateTimeFormat, do we still need to support it for Intl.DisplayNames? If we don't need to support it at all, we could strip the localisations from the ICU data file. See also https://github.com/tc39/proposal-intl-era-monthcode/issues/91.
js> new Intl.DisplayNames("en", {type: "calendar"}).of("islamic-rgsa")
"Hijri Calendar (Saudi Arabia, sighting)"
ICU data filter expression: -/Types/calendar/islamic-rgsa for "lang_tree".
And if complete islamic-rgsa support gets pulled, we could also consider removing the ICU formatter data. (Only used for the non-standard mozIntl.DisplayNames.):
js> var mozIntl = {}; addIntlExtras(mozIntl);
js> new mozIntl.DisplayNames("en-u-ca-islamic-rgsa", {type: "month"}).of(1)
"Muharram"
ICU data filter expression: -/calendar/islamic-rgsa for "locales_tree" and probably also -/calendarData/islamic-rgsa from "supplementalData".
| Reporter | ||
Comment 2•7 months ago
|
||
(In reply to André Bargull [:anba] from comment #1)
If
islamic-rgsagets completely ignored forIntl.DateTimeFormat, do we still need to support it forIntl.DisplayNames?
I think we don't need to support in DisplayNames. It's not used and it's not implemented. The identifier exists only because a project had multi-venue dependencies and something was anticipated and requested and not reverted when left unused. (We have the same risk of multiple moving parts and some level of uncertainty about what the entirety will be once fully baked with pieces of Temporal being split across ECMA and Unicode.)
If we don't need to support it at all, we could strip the localisations from the ICU data file.
That makes sense and would be good for binary size.
Updated•7 months ago
|
| Reporter | ||
Comment 3•3 months ago
|
||
FWIW, it turns out that Safari and Chrome already don't ship a display name for islamic-rgsa.
| Reporter | ||
Comment 4•3 months ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #3)
FWIW, it turns out that Safari and Chrome already don't ship a display name for
islamic-rgsa.
Oops. I was testing French in Safari and Chrome but English in Firefox, and it appears that there's bug in the French data. They do currently ship the display name in e.g English and Finnish. (And the Finnish string is arguably incorrectly translated.)
| Assignee | ||
Comment 5•2 months ago
|
||
Updated•2 months ago
|
| Assignee | ||
Comment 6•2 months ago
|
||
Reduces the ICU data file size by 3056 bytes.
https://hg.mozilla.org/mozilla-central/rev/fa32f0cef636
https://hg.mozilla.org/mozilla-central/rev/0c018f709b8f
Updated•2 months ago
|
Description
•