Japanese new Era name

Victor,

I filed ICU-20153, and checks if other ICU-TC members are OK with it before ICU 63.
ICU 63 code freeze is in this week, so somewhat rushing..

Thanks for sharing your plan!

• Constants for HEISEI/SHOWA/TAISHO/MEIJI will have different values
  Ideally, we prefer the values not being since they have been exposed as public API on Android. But since it wasn't inline-able, so it probably won't break backward comparability. Can you make these constants non-inline-able in ICU4J in ICU 63 and future version of ICU?

For example, I think if the values are initialized in static { } block, the constant won't be inline-able.

Victor - we has some discussion about these constants in ICU TC call recently.
There are several issues related to this -

• These Japanese Calendar era constants are only available in ICU4J API, but not in ICU4C (internal implementation).

• API doc says these values might be changed in a new version of ICU, including HEISEI, SHOWA... because of implementation change.

I also found there are some major issues in Japanese era data. See following CLDR tickets:

• https://unicode.org/cldr/trac/ticket/11375

• https://unicode.org/cldr/trac/ticket/11400

I feel we need to clean up CLDR era data, which also affect these constant values. For example, in late 14th century, two groups of emperor families claimed each of them was legitimate, and separated to North Court and South Court. Each court declared different eras. Thus, history books usually specify both eras (different epochs). In case we need to pick one, eras used by South Court would be used. Unfortunately, current era data contains some eras from North Court, which should be removed. If we do so, era index will be shifted (e.g. Heisei = 235 now, but with the correction, it will be 231(??))/

In addition to this, era epoch date data for Meiji or older eras in CLDR uses a mixture of Lunar calendar month/date and Gregorian/Julian year. It is possible to correct these dates, but ICU needs to implement Japanese Lunar Calendar (a minor variation of Chinese Lunar calendar) to handle these dates properly.

In general, Japanese people is familiar with modern eras back to Meiji (1868). Ordinary people prefer to use Western (Gregorain/Julian) calendar before Meiji (except history books).

For these reasons, I feel I need to clean up Japanese era calendar data after CLDR 35/ICU 63. With my proposal, you would expect:

• Constants for HEISEI/SHOWA/TAISHO/MEIJI will have different values

• Expose these constants in ICU4C

• Clearly document these constant values won't be changed after ICU 64

• Deprecated CURRENT_ERA, but provide a method to get the current era separately.

Yoshito, I have an API question about the constant value for the era names.
https://github.com/unicode-org/icu/commit/61d446f71004311ac7f35e27d770df9d1d7e9201
For example, for the API Japanese.HEISEI,
It was

but changed to

Apparently, the actual value is the same as 235. My question:
1. Were the values of the era constants always the same in the previous version of ICU?
2. The commit makes the constant inline-able by javac. It wasn't the case before the change since I believe CURRENT_ERA is considered dynamic and thus the compiler can figure out the value in compile time. Is the change of inline-ability intentional?

On Android, we care both forward and backward comparability. Thus, inline-ability of an API is considered as an API change on Android API since Android app compiles with different version of stubs and have to run all kinds of ICU4J version.

If the values were not changed and won't get changed, it's likely to be fine on Android. I just want to make sure it's guaranteed.

New tentative Japanese era data is loaded from CLDR, and it's disabled by default.
The environment variable ICU_ENABLED_TENTATIVE_ERA=true (for Java, system property and jdk property in addition to this) will enable the tentative new era for testing.