Integrate with Intl Era and Month Codes proposal

[ptomato]

In all our pseudocode examples supposing a Japanese calendar thus far, we've been passing in era names as lowercased ASCII string identifiers made from English transliterations of the names, e.g. { year: 2, era: 'reiwa' } for the current year. That requires that these identifiers are unique. However, that seems not to be the case as there are several eras written with different kanji but with the same English transliteration.

The ICU names (which I guess must be for output only, not input) disambiguate this by adding a range of years to all of the era names in Latin locales except the most recent five. (For example in the C locale: https://github.com/unicode-org/icu/blob/master/icu4c/source/data/locales/root.txt#L1582-L1818)

What to do for input? Requiring the user to specify the era as a numerical index is extremely unergonomic, (for example, { year: 2, era: 181 }) because they're not otherwise referred to numerically as far as I can tell. This could be mitigated with numeric constants?

There must be some sort of prior art for software that does these calculations.

For background and a list of eras: https://en.wikipedia.org/wiki/Japanese_era_name — disclaimer, all I pretend to know about this calendar comes from that Wikipedia page.

This may be a problem in other calendars as well if they use non-numerical identifiers for things. I don't know if that's the case in any other calendars.

---

These are the duplicate names in the ICU data:

• Jōgen - ISO years 976–978 (貞元) and 1207–1211 (承元)
• Shōryaku - ISO years 990–995 (正暦) and 1077–1081 (承暦)
• Eishō - ISO years 1046–1053 (永承) and 1504–1521 (永正)
• Shōhō - ISO years 1074–1077 (承保) and 1644–1648 (正保)
• Kōwa - ISO years 1099–1104 (康和) and 1381–1384 (弘和)
• Tenshō - ISO years 1131–1132 (天承) and 1573–1592 (天正)
• Kōji - ISO years 1142–1144 (康治) and 1555–1558 (弘治)
• Shōan - ISO years 1171–1175 (承安) and 1299–1302 (正安)
• Jōō - ISO years 1222–1224 (貞応) and 1652–1655 (承応)
• Enkyō - ISO years 1308–1311 (延慶) and 1744–1748 (延享)
• Shōwa - ISO years 1312–1317 (正和) and 1926–1989 (昭和)
• Genkō - ISO years 1321–1324 (元亨) and 1331–1334 (元弘)

Note: Meitoku appears twice as well, from ISO years 1384­–1387 and 1390–1394, but Wikipedia lists just one Meitoku era, and new Date('1385-01-01').toLocaleString('ja-JP-u-ca-japanese', {era: 'short'}) shows the Genchū era instead.

[littledan]

In general, this comes up on the ECMA-402 side of Temporal, where the non-ISO calendars are specified. This comes up for Intl more broadly, e.g., for some future extension of Intl.DisplayNames. For Stage 3, I think it's fine for us to have vague text about the names. This is an action item for the ECMA-402 WG to come to a conclusion on, and should be part of the Stage 4 final integrated spec text.

[Louis-Aime]

How about designing the era optional field of Temporal.Date, rather than a text ? The name of the era would be resolved with the same mechanism as for months and weekdays.

[sffc]

Meiji is the first era in Modern Japan. One idea therefore would be to adopt a scheme such as:

• era10001 = Meiji
• era10002 = Taishō
• era10003 = Shōwa
• era10004 = Heisei
• era10005 = Reiwa

Eras prior to Meiji can be inserted in descending order, like:

• era09990 = Keiō
• era09980 = Genji
• era09970 = Bunkyū

I intentionally left one extra digit at the end in case eras need to be added in the future. I'm told that as we get far back into Japanese history, eras are sometimes still being discovered.

[Louis-Aime]

Is there any official Japanese institution that handles this issue ? The Temporal team could then take into account the way they "code" the eras, if they do so. And how they do if they discover new eras in the past.

[Manishearth]

So I and @sffc have been discussing some options and tradeoffs, and we want to eventually present them, but first I wanted a quick temperature check: How do people feel about just using Kanji for the era names? It's guaranteed to be unique, and ultimately these are identifiers so people can copy-paste them.

The downsides are:

• There's a potential for encoding issues
• Web APIs typically use ASCII identifiers, this is a departure
• This is bound to be somewhat controversial, though to some extent I think it's good to push developers out of the ascii bubble.

Mostly looking to see if people think this is a good idea, if they think it's a good idea but have some reservations (which we can weigh when we look at the tradeoffs), or if they think it's a really bad idea and should be excluded from consideration.

[macchiati]

When we are talking about programmatic identifiers (not user strings), as limiting as it is, ASCII alphanums have the advantage of :

• being recognizable by essentially all programmers
• useful in protocols that limit the character set (eg BCP47)

[ptomato]

I don't think it's a bad idea but I also don't think pushing developers out of an ASCII / C-locale / Gregorian bubble is a design goal of Temporal. Rather, it's a goal to make doing the right thing the easiest course of action. I don't see this significantly contributing in that way.

[Manishearth]

@ptomato yeah the primary goal of that proposal is that it avoids a bunch of other tradeoffs due to the ascii requiring disambiguators. It does seem like it's worth talking about, though perhaps may not be the winner when we weigh all the other tradeoffs against each other

[justingrant]

If names are problematic, I don't see a problem with a scheme like @sffc described above in #526 (comment).

A hybrid approach could be pairing a numeric code with a transliterated string, e.g. 10001_meiji, 10002_taisho, etc. Even if the word part is duplicated, the number could disambiguate. Keep in mind that these strings are never supposed to be shown to end users, so IMHO it really doesn't matter what they are as long as they can be read and copy/pasted easily.

I'd strongly suggest sticking to ASCII for the reasons noted above. In particular, using Kanji seems fraught with potential problems because a lot of localized software development and debugging happens by developers who aren't fluent in the language being used. Using characters that are not readable by the developers writing the code seems like a bad idea.