Get era code defined in UTS35 / CLDR instead

[FrankYFTang]

@sffc came to my cube and mentioned some people suggested we delegate / forward of the era code to another standard, in Unicode code instead.

Here are what currently CLDR define for era code:
https://github.com/unicode-org/cldr/blob/main/common/supplemental/supplementalData.xml#:~:text=%3CcalendarData%3E

in the type attribute of the <eras>

    <calendarData>
        <calendar type="gregorian">
           <calendarSystem type="solar" />
           <eras>
               <era type="0" end="0-12-31" />
               <era type="1" start="1-01-01" />
           </eras>
        </calendar>
        <calendar type="generic"/>
                <!-- gregorian territories are assumed, so these are all in addition -->
        <calendar type="japanese">
          <calendarSystem type="solar" />
          <eras>
...
              <era type="233" start="1912-7-30"/>
              <era type="234" start="1926-12-25"/>
              <era type="235" start="1989-1-8"/>
              <era type="236" start="2019-5-1"/>
          </eras>
        </calendar>
        <calendar type="islamic">
          <calendarSystem type="lunar" />
          <eras>
              <era type="0" start="622-7-15"/>
          </eras>
        </calendar>
        <calendar type="islamic-civil">
          <calendarSystem type="lunar" />
          <eras>
              <era type="0" start="622-7-16"/>
          </eras>
        </calendar>
        <calendar type="islamic-rgsa">
          <calendarSystem type="lunar" />
          <eras>
              <era type="0" start="622-7-15"/>
          </eras>
        </calendar>
        <calendar type="islamic-tbla">
          <calendarSystem type="lunar" />
          <eras>
              <era type="0" start="622-7-15"/>
          </eras>
        </calendar>
        <calendar type="islamic-umalqura">
          <calendarSystem type="lunar" />
          <eras>
              <era type="0" start="622-7-15"/>
          </eras>
        </calendar>
        <calendar type="chinese">
          <calendarSystem type="lunisolar"/>
          <eras>
              <era type="0" start="-2636-01-01"/> <!-- 'sequential' year -->
          </eras>
        </calendar>
        <calendar type="hebrew">
          <calendarSystem type="lunisolar"/>
          <eras>
              <era type="0" start="-3760-10-7"/>
          </eras>
        </calendar>
        <calendar type="buddhist">
          <calendarSystem type="solar" />
          <eras>
              <era type="0" start="-542-01-01"/>
          </eras>
        </calendar>
        <calendar type="coptic">
          <calendarSystem type="other"/>
          <eras>
              <era type="0" end="284-08-28"/>
              <era type="1" start="284-08-29"/>
          </eras>
        </calendar>
        <calendar type="persian">
          <calendarSystem type="solar"/>
          <eras>
              <era type="0" start="622-01-01"/>
          </eras>
        </calendar>
        <calendar type="dangi">
          <calendarSystem type="lunisolar"/>
          <eras>
              <era type="0" start="-2332-01-01"/> <!-- 'sequential' year -->
          </eras>
        </calendar>
        <calendar type="ethiopic">
          <calendarSystem type="other"/>
          <eras>
              <era type="0" end="8-08-28"/>
              <era type="1" start="8-08-29"/>
          </eras>
        </calendar>
        <calendar type="ethiopic-amete-alem">
          <eras>
              <era type="0" end="-5492-08-29"/>
          </eras>
        </calendar>
        <calendar type="indian">
          <eras>
              <era type="0" start="79-01-01"/>
          </eras>
        </calendar>
        <calendar type="roc">
          <eras>
              <era type="0" end="1911-12-31"/>
              <era type="1" start="1912-01-01"/>
          </eras>
        </calendar>

    </calendarData>

I do not think for JavaScript web developer, using "0", "1", "233", "234", "235", "236" has good readability. If you prefer to use these 6 values which defined in CLDR for era code, please express a support. If you prefer NOT to use these 6 values which defined in CLDR for era code, please also express your oppisition.

I think we should define string map to these defintion, but not use these value in the API surface. for example, we should map "bce" to type="0" in gregorian calendar, and "mg" map to type="1" in roc calendar.

[FrankYFTang]

Notice, in ECMA402, we have define many string values, sometime to represent concept in UTS35 / CLDR with a different lexical value, already:

Table 2: Single units sanctioned for use in ECMAScript
defines many units
https://tc39.es/ecma402/#table-sanctioned-single-unit-identifiers
This is mirrowing subset of ids from https://github.com/unicode-org/cldr/blob/main/common/validity/unit.xml

Table 3: Effects of Collator Sensitivity
defines string value "base", "accent", "case", "variant"
https://tc39.es/ecma402/#table-collator-comparestrings-sensitivity

Table 5: Range pattern fields
Defines string values "era", "year", "month", "day", "ampm", "dayPeriod", "hour", "minute", "second", "fractionalSecondDigits"
https://tc39.es/ecma402/#table-datetimeformat-rangepatternfields
I am pretty sure nowhere in CLDR define the string values "ampm" and "fractionalSecondDigits"

Table 7: Components of date and time formats
Defines string values "2-digit", "numeric", "narrow", "short", "long", "shortOffset", "longOffset", "shortGeneric", "longGeneric"
https://tc39.es/ecma402/#table-datetimeformat-components
I am pretty sure nowhere in CLDR define the string values "2-digit" "shortOffset", "longOffset", "shortGeneric", and "longGeneric"

Table 10: Codes For Date Time Field of DisplayNames
Defines string values "era", "year", "quarter", "month", "weekOfYear", "weekday", "day", "dayPeriod", "hour", "minute", "second", "timeZoneName"
https://tc39.es/ecma402/#table-validcodefordatetimefield
I am pretty sure nowhere in CLDR define the string value "timeZoneName"

Table 13: Numbering systems with simple digit mappings
https://tc39.es/ecma402/#table-numbering-system-digits
This is mirrowing the definition in
https://github.com/unicode-org/cldr/blob/main/common/supplemental/numberingSystems.xml

Notice, while Table 2 and Table 13 just mirrow the full or subset of what listed in CLDR, other tables above defined string values which is not defined in CLDR.

[sffc]

CC @ryzokuken @ptomato @romulocintra

[sffc]

I think it would be okay to follow the model of numbering systems, units, etc., where we reference an existing specification or data file and copy the codes into ECMA-402.

The codes should originate somewhere else that we can point to, which we may need to create.

[FrankYFTang]

ok, see the right most column "Type of <eras> in CLDR " in Table 2: Range of eraYear
https://frankyftang.github.io/proposal-intl-era-monthcode/#table-erayear-range
that is " reference an existing specification or data file and copy the codes into ECMA-402."

[ptomato]

I think it would be great to get the string aliases into CLDR, and reference them from ECMA-402. Era data can change without implying adding new logic to ECMAScript, unlike the other examples you gave such as collator sensitivity and date-time format components. The situation I would like to avoid is that a new era is adopted into CLDR and then we have to make a normative change to add its string alias.

[sffc]

The codes are in cldr. We should close this issue once they are updated:

unicode-org/cldr#4519

[ptomato]

I'm going to remove this from the Stage 2.7 milestone, as I don't think it is an obstacle for stage advancement.

[ptomato]

The CLDR change has been merged.