<i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era

Naoto Sato naoto.sato at oracle.com
Thu Sep 7 17:28:41 UTC 2017


Mitsuru-san,

By those options I meant to address the inconsistency in 
SimpleDateFormat, between COMPAT and CLDR, for the existing eras (e.g. 
Heisei). As to the inconsistency you wrote below, I am not sure that's 
worth doing, considering 1) it is aligned with CLDR, 2) supplemental era 
functionality is for emergency situations till the era is officially 
supported.

Naoto



On 9/6/17 11:16 PM, Mitsuru Matsushima wrote:
> Hi, Naoto-san,
> 
>> So, considering these, I have a couple of options. One is to use the newer
>> java.time.format APIs which can correctly handle
>> this, or use the
>> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
> 
> Hmm, I think the first option is ok.
> However, the second one seems to be confused >
> I guess the behaviors with COPMAT and Supplemental Era become follows:
> 
> * COMPAT (SimpleDateFormat)
>   Long: Heisei
>   Short: H
> 
> * COMPAT (DateTimeFormatter)
>   Long: Heisei
>   Short: H
>   Narrow: H
> 
> * Supplemental Era (SimpleDateFormat)
>   Long: NewEra
>   Short: N.E
> 
> * Supplemental Era (DateTimeFormatter)
>   Long: NewEra
>   Short: NewEra
>   Narrow: N.E
> 
> If this is true, the short value of Supplemental Era differs from COMPAT.
> So CalendarNameProviderImpl should be conscious about the type of provider.
> 
> ---
> Mitsuru
> 
>> -----Original Message-----
>> From: Naoto Sato [mailto:naoto.sato at oracle.com]
>> Sent: Saturday, September 02, 2017 2:49 AM
>> To: Matsushima Mitsuru(松島 充) <m-matsushima at bk.jp.nec.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
>> <i18n-dev at openjdk.java.net>
>> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
>>
>> Hi Mitsuru-san,
>>
>> Yes, I remember we discussed on this issue before. The reason that LONG and SHORT names for Japanese era are the same
>> is that CLDR's era names are not very consistent on length. They have "eraNames", "eraAbbr", and "eraNarrow" variations.
>> We simply assign LONG to eraNames and SHORT to eraAbbr in SimpleDateFormat. Possibly the right solution is to provide
>> "narrow" option in SimpleDateFormat, but it would be breaking the compatibility (text length of those pattern characters
>> just have two options, one is 4 or greater (=LONG), and the other is less than 4 (=SHORT)).
>>
>> So, considering these, I have a couple of options. One is to use the newer java.time.format APIs which can correctly handle
>> this, or use the
>> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
>>
>> HTH,
>> Naoto
>>
>> On 8/31/17 7:34 PM, Mitsuru Matsushima wrote:
>>> Hi Naoto-san,
>>>
>>> The fix looks good, though I'm not a reviewer...
>>>
>>> By the way, I may have forgotten to inform you that there exist an issue at the short form of SimpleDateFormat has an
>> issue.
>>>
>>> The SimpleDateFormat class is only capable to treat two form, Short and Long.
>>> At JDK9, the CLDR Provider become to default, the provider returns the same value for the Short form and the Long form.
>>> So, the behavior of SimpleDateFormat is incompatible to previous versions.
>>> (See the Comparison table, I described before.)
>>>
>>> ---
>>> Mitsuru
>>>
>>>> -----Original Message-----
>>>> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf
>>>> Of Naoto Sato
>>>> Sent: Thursday, August 31, 2017 7:56 AM
>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
>>>> <i18n-dev at openjdk.java.net>
>>>> Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
>>>> supplemental Japanese era
>>>>
>>>> Hi,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8180469
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8180469/webrev.00/
>>>>
>>>> The problem was caused by the difference of the Era display name for "SHORT" style between java.time and java.util.Calendar.
>>>>
>>>> Naoto
> 


More information about the i18n-dev mailing list