Closed MenoData closed 7 years ago
A good alternative is to postpone this issue in favor of introducing a simplified JapaneseGregorianCalendar
which is valid since Mejii 6 (1873).
Side note: New eras (for a new yet unknown emperor) should be supported, too. A solution should also take into account the new JDK-property "jdk.calendar.japanese.supplemental.era" (scheduled for Java-9 ???):
/**
* {@code JapaneseImperialCalendar} implements a Japanese
* calendar system in which the imperial era-based year numbering is
* supported from the Meiji era. The following are the eras supported
* by this calendar system.
* <pre>{@code
* ERA value Era name Since (in Gregorian)
* ------------------------------------------------------
* 0 N/A N/A
* 1 Meiji 1868-01-01T00:00:00 local time
* 2 Taisho 1912-07-30T00:00:00 local time
* 3 Showa 1926-12-25T00:00:00 local time
* 4 Heisei 1989-01-08T00:00:00 local time
* ------------------------------------------------------
* }</pre>
*
* <p>{@code ERA} value 0 specifies the years before Meiji and
* the Gregorian year values are used. Unlike
* {@link GregorianCalendar}, the Julian to Gregorian transition is not
* supported because it doesn't make any sense to the Japanese
* calendar systems used before Meiji. To represent the years before
* Gregorian year 1, 0 and negative values are used. The Japanese
* Imperial rescripts and government decrees don't specify how to deal
* with time differences for applying the era transitions. This
* calendar implementation assumes local time for all transitions.
*
* <p>A new era can be specified using property
* jdk.calendar.japanese.supplemental.era. The new era is added to the
* predefined eras. The syntax of the property is as follows.
* <pre>
* {@code name=<name>,abbr=<abbr>,since=<time['u']>}
* </pre>
* where
* <dl>
* <dt>{@code <name>:}<dd>the full name of the new era (non-ASCII characters allowed)
* <dt>{@code <abbr>:}<dd>the abbreviation of the new era (non-ASCII characters allowed)
* <dt>{@code <time['u']>:}<dd>the start time of the new era represented by
* milliseconds from 1970-01-01T00:00:00 local time or UTC if {@code 'u'} is
* appended to the milliseconds value. (ASCII digits only)
* </dl>
*
* <p>If the given era is invalid, such as the since value before the
* beginning of the last predefined era, the given era will be
* ignored.
*
* <p>The following is an example of the property usage.
* <pre>
* java -Djdk.calendar.japanese.supplemental.era="name=NewEra,abbr=N,since=253374307200000"
* </pre>
* The property specifies an era change to NewEra at 9999-02-11T00:00:00 local time.
*
* @author Masayoshi Okutsu
* @since 1.6
*/
class JapaneseImperialCalendar extends Calendar {...}
Another important point: Concrete dates for era change only makes sense for all modern eras since Meji. Eras before Meji can completely overlap with next era, i.e., there is no concept for a special date of era change. So specifying a year either as KEIO 4 or MEIJI 1 is both okay for every date of related gregorian year 1868. This has to be taken into account for parsing japanese eras and years (note also that some eras have same name like SHOWA, JOGEN etc.!). Printing will need any kind of arbitrary era choice in such ambivalent (lunar) years, maybe just selecting the first day of lunar year as era start. The choice of ICU4J of era changes seems to be arbitrary (and I don't see any citation of the source of those data). Here an extract of ICU4J-source code:
private static final int[] ERAS = { // Gregorian date of each emperor's ascension // Years are AD, months are 1-based. // Year Month Day 645, 6, 19, // Taika 650, 2, 15, // Hakuchi 672, 1, 1, // Hakuho 686, 7, 20, // Shucho 701, 3, 21, // Taiho 704, 5, 10, // Keiun 708, 1, 11, // Wado 715, 9, 2, // Reiki 717, 11, 17, // Yoro 724, 2, 4, // Jinki 729, 8, 5, // Tempyo 749, 4, 14, // Tempyo-kampo 749, 7, 2, // Tempyo-shoho 757, 8, 18, // Tempyo-hoji 765, 1, 7, // Tempho-jingo 767, 8, 16, // Jingo-keiun 770, 10, 1, // Hoki 781, 1, 1, // Ten-o 782, 8, 19, // Enryaku ...
At least the first line with the date 645-06-19 for the start of era TAIKA is surely not correct because the date should be Julian not Gregorian (according to other sources). And the other dates strongly deviate from what is given in http://oriens-extremus.org/wp-content/uploads/2016/08/OE-28.2-7.pdf
Conclusion: It is probably best not to choose ICU4j-data but just use the first day of lunar year as era start by default and make the concrete printing of era in such years of era change configurable by any kind of era-change-policy.
About the idea to first introducing a simplified Japanese-Gregorian calendar, this is now rejected. Am actually working on gathering the full data based on the work of Paul Yachita Tsuchihashi (a big work but half is already done).
The first year of a new nengo (era) is also called "Gannen" (元年). Not supported by Java-8, but by SimpleDateFormat
, see this old unsolved issue:
http://mail.openjdk.java.net/pipermail/threeten-dev/2013-April/001284.html
Maybe Time4J could use a special number format...
Another oddity in Java-8 is the handling of "yy"-pattern. It should not be used as two-digit-year like in other calendars:
Before 1873, it is partially based on Chinese calendar. Investigation is needed for this ancient part of history. See also:
http://www.yukikurete.de/nengo_calc.htm http://wiki.samurai-archives.com/index.php?title=Japanese_calendar https://en.wikipedia.org/wiki/List_of_Japanese_era_names https://en.wikipedia.org/wiki/Japanese_calendar http://www.iudicium.de/katalog/783-1.htm http://oriens-extremus.org/wp-content/uploads/2016/08/OE-28.2-7.pdf http://www.bernhardpeter.de/Kalender/seite482.htm http://www.renshaworks.com/jastro/calendar.htm http://www.i18nguy.com/l10n/emperor-date.html
It is only simple for dates after Meji reform and - this way - implemented in Java-8. But support for older dates is completely missing.