Kishida-san, I further looked into this. Although JapaneseDate itself does not accept H32, DateTimeFormatter does support lenient mode, e.g., a formatter created with withResolverStyle(ResolverStyle.LENIENT) does accept dates like "Heisei 32." Date/time formatter in java.text that use java.util.Calendar instances accept lenient dates by default. HTH, Naoto On 6/14/18 4:00 PM, Naoto Sato wrote:

Hi,

Yes, that's the expected behavior with the implementation assuming "Heisei 32" is non-existent. I see some discussion as you mentioned, whether to allow to use Heisei for a while, for transitional purpose, but at the moment there's very little & no official information available. We may consider adding an additional API to convert those dates leniently.

Naoto

On 6/14/18 5:13 AM, kishida naoki wrote:

...

I'm trying to use the Japanese new era supporting and have found that it does not accept Heisei 32. There are many document that include Heisei 32 or later at present. For example, the expiration date of my driver license is Heisei 32 March. JDK10 can accept Heisei 32. I think the change of the behavior make some trouble.

Additionally,  Japanese government says some system use Heisei after 5/1/2019 for a while. The JDK version that include the new era support can not be used on such system. https://digital.asahi.com/articles/DA3S13491490.html

There are 3 ways to support the new era. 1. H32 is not accepted and S90 is not accepted. (current new era support behavior) 2. H32 is accepted and S90 is not accepted. (current JDK behavior) 3. H32 is accepted and S90 is accepted. (to conformity)

I prefer 2 not to change the current JDK behavior.

With taking 2 or 3, we might have a new API like JapaneseDate.from(JapaneseEra, TemporalAccessor) to specify an era on making JapaneseDate.