Japanese New Era supporting does not accept Heisei 32

[Naoto Sato]

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.
>>