FULL PRODUCT VERSION :
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Can replicate on multiple OS (Win 7 / OS X)
A DESCRIPTION OF THE PROBLEM :
Following output:
System.out.println(LocalDate.of(2015, Month.MAY, 1).format(DateTimeFormatter.ofPattern("dd-LLL-yyyy",Locale.US)));
Should show something like "01-of May-2015", but shows "01-5-2015".
However, printed using he Russian Locale:
System.out.println(LocalDate.of(2015, Month.MAY, 1).format(DateTimeFormatter.ofPattern("dd-LLL-yyyy",Locale.forLanguageTag("ru"))));
It prints correctly: 01-Май-2015
LLL is supposed to be the textual representation for the "Long form" of the month. I have tried with several default language implementations, and it is constantly a hit and miss. This definitely should get corrected for Local.US. For other languages, if no proper implementation, it should default to the short textual form, and not the numeric form.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
As the 'L' specifier is newly introduced in Java 8, it is not going to have huge impact. Also it is not a regression.
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Can replicate on multiple OS (Win 7 / OS X)
A DESCRIPTION OF THE PROBLEM :
Following output:
System.out.println(LocalDate.of(2015, Month.MAY, 1).format(DateTimeFormatter.ofPattern("dd-LLL-yyyy",Locale.US)));
Should show something like "01-of May-2015", but shows "01-5-2015".
However, printed using he Russian Locale:
System.out.println(LocalDate.of(2015, Month.MAY, 1).format(DateTimeFormatter.ofPattern("dd-LLL-yyyy",Locale.forLanguageTag("ru"))));
It prints correctly: 01-Май-2015
LLL is supposed to be the textual representation for the "Long form" of the month. I have tried with several default language implementations, and it is constantly a hit and miss. This definitely should get corrected for Local.US. For other languages, if no proper implementation, it should default to the short textual form, and not the numeric form.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
As the 'L' specifier is newly introduced in Java 8, it is not going to have huge impact. Also it is not a regression.
- duplicates
-
JDK-8008577 Use CLDR Locale Data by Default
-
- Closed
-
- relates to
-
JDK-8160225 java.time.format.DateTimeFormatter issues for month-of-year
-
- Closed
-