Add generic calendar as the base for all non-gregorian calendars


Deleted Component: other

This is the longer-term enhancement split out of :

We should add a "generic" calendar in root as the base from which all non-gregorian calendars inherit. This would (at least) add eras to all formats with year. Individual locales might be able to just tailor this generic calendar instead of separately tailoring each non-gregorian calendar (often they are all tailored in the same way). Locales could still have distinct tailorings for specific non-gregorian calendars when necessary.

Also, we should add an availableFormats Gy item in root and the generic calendar, or else make sure that appendItems handles it correctly.






May 10, 2019, 3:57 AM
Trac Comment 11 by —2014-04-22T20:37:44.756Z

Milestone 23dres deleted

May 10, 2019, 3:57 AM
Trac Comment 9 by —2013-02-19T11:03:29.442Z

Made some further corrections based on analysis of ICU test run with many locales / 7 calendars for each / standard patterns + 66 skeletons + 17 interval formats.

May 10, 2019, 3:57 AM
Trac Comment 8 by —2013-02-14T17:52:03.493Z

r8188 had a date format typo in pt_PT, fixed by Mark in r8191.

May 10, 2019, 3:57 AM
Trac Comment 7 by —2013-02-14T09:28:18.321Z

Actually, the approach above had an issue; deleting anything from gregorian causes massive problems in ICU. Instead I flipped around the inheritance so now gregorian is at the top. Most items are inherited directly from gregorian, but non-gregorian locales inherit dateFormats and dateTimeFormats (incl availableFormats, intervalFormats) from "generic". I deleted all of the now unused stuff in "generic" for all locales in common/main, changed the inheritance in root to the new structure, and made specific tweaks in 30+ locales as follows -

  • Adjusted generic availableFormats & intervalFormats to show era

  • Added availableFormats for Gy,GyMMM,GyMMMd,GyMMMEd for :

  • Adjusted most non-Gregorian availableFormats with y to have 4-y skeletons (and 1-y patterns)

  • Deleted calendar format data for specific non-Gregorian calendars that ois now redundant due to the generic calendar data in the locale

The locales handled tweaked in this way are (in addition to root): ar cs da de de_AT en en_AU en_CA en_GB es es_419 fi fr fr_BE fr_CA fr_CH he it it_CH ja ko nb nl nl_BE pl pt pt_PT ru sv th tr zh zh_Hant

Even without tweaking, the generic calendar data provides formatting improvements in most locales. If they already have specific format data for a non-Gregorian calendar is does not override that, but when the locale does not, it provides formatting that is consistent with gregorian (although without tweaking the availableFormats and intervalFormats will not include era, though the standard formats already do for all generic data).

I have filed : for the further tweaks.

May 10, 2019, 3:57 AM
Trac Comment 6 by —2013-02-11T09:31:21.084Z

There is a bootstrapping issue with implementing this, so it has to be done in two phases.

Part 1 is fairly mechanical and straightforward: for all locales (common and seed), copy the current "gregorian" data to "generic", deleting the month and eras; then adjust the standard date formats (not yet the others) to change all yyyy to y, and to add eras: GGGGG for short format, g for the others. This I am doing in a couple of batches.

This needs to be integrated into ICU, and the ICU code changed in a few places to fall back to "generic" instead of "gregorian". We nned to move a copy of ICU4J with those changes back to CLDR for its tests. Then we can move to Part 2, which does the following:

  • Set up the proper inheritance in root

  • For all locales, delete date symbols data from "gregorian" that is present in "generic": day names, day periods, quarters.

  • For selected locales (as many as possible given the time available), adjust the "generic" standard formats, availableFormats, and intervalFor,ate; then delete as much as possible of the non-gregorian calendar data.




Peter Edberg


Peter Edberg


John Emmons