JDK-8180469 : Wrong short form text for supplemental Japanese era
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-05-16
  • Updated: 2019-05-21
  • Resolved: 2017-08-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 8 Other
10 b22Fixed 8u211Fixed openjdk8u212Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+169)
Java HotSpot(TM) Server VM (build 9-ea+169, mixed mode, emulated-client)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
By JDK-8173423, the issue of the wrong formatted string for a supplemental new era is resolved. However, there is new issue for the short form.

At the Japanese Era, the JDK's built-in resource for the short form of Eras are same to the full form. Dispite of this, The changes on JDK-8173423, the CalendarDataProviderImpl returns Era.getName() value if only the LONG style requested.Thus, Era.getAbbreviation() value is returned when the short form is requested.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The following code snippet demonstrate the issue (" -Djdk.calendar.japanese.supplemental.era=name=NewEra,abbr=N.E.,since=1546300800000" is given on invocation):

--
        LocalDate ldHeisei = LocalDate.of(2018, 1, 1);
        LocalDate ldNewEra = LocalDate.of(2019, 1, 1); // first day of NewEra 
        DateTimeFormatter dtf = DateTimeFormatter.ofPattern("GGGGG GGGG G")
                .withChronology(JapaneseChronology.INSTANCE)
                .withLocale(Locale.US);
        System.out.println(dtf.format(ldHeisei));
        System.out.println(dtf.format(ldNewEra));
--

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
H Heisei Heisei
N.E. NewEra NewEra

ACTUAL -
H Heisei Heisei
N.E. NewEra N.E.

REPRODUCIBILITY :
This bug can be reproduced always.


Comments
Further information from the customer: --- At the Comparison table, I added the "Supplemental Era" behavior and "Expected?" behavior. Japanese usually use '���' or 'H' for abbreviated name of "������". Thus, I think it's useful that the both of them are usable. So I added the "Expected?" behavior. (Ah, however it seems difficult that different behavior for short form...) (I don't know why CLDR don't describe wide name for Japanese era and why describe wide name as abbreviated name.) Comparison table: ======================================= | SimpleDateFormat| DateTimeFormatter |--------|--------|--------|--------|-------- | Full | Short | Full | Short | Narrow ------------------|--------|--------|--------|--------|-------- COMPAT | ������ | H | ������ | H | H CLDR | ������ | ������ | ������ | ������ | H HOST | ������ | ��� | ������ | ��� | ������ ------------------|--------|--------|--------|--------|-------- Supplemental Era | NewEra | N.E | NewEra | N.E | N.E ------------------|--------|--------|--------|--------|-------- Expected? | ������ | H | ������ | ��� | H ======================================= Test code: Execute with java.locale.provider system property. ======================================= public class SupplementalEraTest2 { public static void main(String... args) { System.out.println("java.locale.providers=" + System.getProperty("java.locale.providers")); // set supplemental era System.setProperty( "jdk.calendar.japanese.supplemental.era", "name=NewEra,abbr=N.E,since=1546300800000"); final int[][] dateSrcs = { //{1989, 1, 7}, {1989, 1, 8}, // Heisei before and after {2018, 12, 31}, {2019, 1, 1}, // NewEra before and after }; System.out.println(">>>>> SimpleDateFormat"); printWithSimpleDateFormat(dateSrcs); System.out.println(">>>>> DateTimeFormatter"); printWithDateTimeFormatter(dateSrcs); } private static void printWithSimpleDateFormat(int[][] dateSrcs) { final Locale jpLocale = new Locale("ja", "JP", "JP"); final Calendar cal = Calendar.getInstance(); final Date[] dates = Arrays.stream(dateSrcs) .map((int[] d) -> { // first month is 0 cal.set(d[0], d[1] - 1, d[2], 0, 0, 0); return cal.getTime(); }).toArray(Date[]::new); System.out.println("---Full format"); SimpleDateFormat fmtLong = new SimpleDateFormat( "GGGG", jpLocale); Arrays.stream(dates).map(fmtLong::format).forEach(System.out::println); System.out.println("---Short format"); SimpleDateFormat fmtShort = new SimpleDateFormat( "G", jpLocale); Arrays.stream(dates).map(fmtShort::format).forEach(System.out::println); } private static void printWithDateTimeFormatter(int[][] dateSrcs) { final Locale jpLocale = new Locale("ja", "JP", "JP"); final LocalDate[] lDates = Arrays.stream(dateSrcs) .map((int[] d) -> LocalDate.of(d[0], d[1], d[2])) .toArray(LocalDate[]::new); System.out.println("---Full format"); final DateTimeFormatter fmtrFull = DateTimeFormatter.ofPattern("GGGG") .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); Arrays.stream(lDates).map(fmtrFull::format).forEach(System.out::println); System.out.println("---Short format"); DateTimeFormatter fmtrShort = DateTimeFormatter.ofPattern("G") .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); Arrays.stream(lDates).map(fmtrShort::format).forEach(System.out::println); System.out.println("---Narrow format"); DateTimeFormatter fmtrNarrow = DateTimeFormatter.ofPattern("GGGGG") .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); Arrays.stream(lDates).map(fmtrNarrow::format).forEach(System.out::println); } } =======================================
22-06-2017

Additional information from submitter: The HOST provider has similar issue. The short form and the narrow form need to be swapped. This issue is not only supplemental era, but also existing era. To reproduce this issue, Windows with Japanese language environment is needed. The following code snippet demonstrate the issue (" -Djava.locale.providers=HOST" is given on invocation): -- LocalDate ldHeisei = LocalDate.of(2018, 1, 1); DateTimeFormatter dtf = DateTimeFormatter.ofPattern("GGGGG GGGG G") .withChronology(JapaneseChronology.INSTANCE) .withLocale(new Locale("ja", "JP", "JP")); System.out.println("NARROW(GGGGG) FULL(GGGG) SHORT(G)"); System.out.println(dtf.format(ldHeisei)); -- EXPECTED - NARROW(GGGGG) FULL(GGGG) SHORT(G) ������ ������������ ������������ ACTUAL - NARROW(GGGGG) FULL(GGGG) SHORT(G) ������������ ������������ ������
20-06-2017

To reproduce the issue, run the attached test case with the VM argument : -Djdk.calendar.japanese.supplemental.era=name=NewEra,abbr=N.E.,since=1546300800000 JDK 9ea+168 - Fail Output: H Heisei Heisei N.E. NewEra N.E.
17-05-2017