Re: [10] RFR 8180469: Wrong short form text for supplemental Japanese era

2017-09-10 Thread Mitsuru Matsushima
(outside of supplementary era support) is that "G" > pattern for SimpleDateFormat outputs differently between COMPAT provider > and CLDR provider, e.g., COMPAT returns "H" and CLDR returns "Heisei", > which comes from CLDR data using "Heisei" for "

Re: [10] RFR 8180469: Wrong short form text for supplemental Japanese era

2017-09-08 Thread Mitsuru Matsushima
sidering 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 th

Re: [10] RFR 8180469: Wrong short form text for supplemental Japanese era

2017-09-06 Thread Mitsuru Matsushima
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. >

Re: [10] RFR 8180469: Wrong short form text for supplemental Japanese era

2017-08-31 Thread Mitsuru Matsushima
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 b

Re: The first year skipped when using UTC time for "jdk.calendar.sypplemental.era" system property

2017-06-22 Thread Mitsuru Matsushima
a.net > Subject: Re: The first year skipped when using UTC time for > "jdk.calendar.sypplemental.era" system property > > Hi Matsushita-san, > > I will look into it. Could you please file an issue about this? > > Naoto > > On 6/22/17 6:20 PM, Mitsuru M

The first year skipped when using UTC time for "jdk.calendar.sypplemental.era" system property

2017-06-22 Thread Mitsuru Matsushima
Hi, I found an issue about "jdk.calendar.sypplemental.era" system property. According toJavadoc of JapaneseImperialCalendar, the system property can specify "since" parameter as UTC time. However, on using UTC time, the first year of new era is skipped. The new era start with a second year as f

Re: Additional infomation for JDK-8048123

2017-06-22 Thread Mitsuru Matsushima
it along > with the supplemental era's short name inconsistency. > > Naoto > > On 6/22/17 1:36 PM, Mitsuru Matsushima wrote: > > At the Comparison table, I added the "Supplemental Era" behavior and > > "Expected?" behavior. > > Japanese usual

Re: Additional infomation for JDK-8048123

2017-06-22 Thread Mitsuru Matsushima
Sorry, I did not know the mailing list strips out attachments. (Thanks for telling me, Martin.) I try to write down the test code and comparison table image below. At the Comparison table, I added the "Supplemental Era" behavior and "Expected?" behavior. Japanese usually use '平' or 'H' for abbre

Additional infomation for JDK-8048123

2017-06-21 Thread Mitsuru Matsushima
Hi. I reported JDK-8048123 before. But I notice this issue is more complex. It's unable to attach files at the web form, so I post to ml. At first, I thought it's a issue of the fix for JDK-8173423. However, I think it's a issue of CalendarNameProviders now. I tested attatched AupplementalEraTe