JDK-8114833 : java.time.format.DateTimeFormatter does not work as documented
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 8u45
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: os_x
  • CPU: x86
  • Submitted: 2015-06-15
  • Updated: 2017-04-10
  • Resolved: 2017-04-10
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 9
9Resolved
Related Reports
Duplicate :  
Relates :  
Description
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.


Comments
CLDRConverter was modified to handle standalone/format names correctly as part of JDK-8008577. We will need to backport part of the fix if it is really needed in JDK-8.
10-04-2017

Can not reproduce with jdk-9 b135 on Mac10.11 and windows8.1. Hence removing 9 form the affected version
12-09-2016

See also https://bugs.openjdk.java.net/browse/JDK-8146356
02-05-2016

I did a check with 9b112 on windows x64 machine it worked fine but it's failed with 8u66 on same machine
10-04-2016

I agree with the desire of the issue, however, the use of "L" as a pattern letter appears to roughly match SimpleDateFormat: System.out.println(new SimpleDateFormat("dd-LLL-yyyy", Locale.US).format(new Date())); System.out.println(LocalDate.now().format(DateTimeFormatter.ofPattern("dd-LLL-yyyy", Locale.US))); System.out.println(new SimpleDateFormat("dd-LLL-yyyy", Locale.forLanguageTag("ru")).format(new Date())); System.out.println(LocalDate.now().format(DateTimeFormatter.ofPattern("dd-LLL-yyyy", Locale.forLanguageTag("ru")))); I'd be happy to see pattern letter L (standalone text) be changed so that it defaults to the same as M (non-standalone) if no standalone data is available for a language. This is what is intended by CLDR data IIUC.
17-06-2015

1. Run the attached test case play.java in MAC OS X and Linux (64-bit). 2. Checked this for JDK 8, 8u45, 8u60 ea b19, and 9 ea b68. 8: FAIL 8u45: FAIL 8u60 ea b19: FAIL 9 ea b68: FAIL 3. Output with JDK 8u45: -------------------------------------- (See attached test_report.txt) 4. Conclusion: This issue is reproducible with JDK 8u45 and 9 ea b68 as reported by the submitter. Moving this up for further evaluation.
17-06-2015