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.
