JDK-8146356 : java.time.format.TextStyle.FULL_STANDALONE does not work well while formatting months.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 8u66
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-11-16
  • Updated: 2020-03-11
  • Resolved: 2020-03-11
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 8
8u261Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows 10 x64

A DESCRIPTION OF THE PROBLEM :
java.time.format.TextStyle.FULL_STANDALONE does not work well while formatting months.

For example:
System.out.println(Month.of(3).getDisplayName(TextStyle.FULL_STANDALONE, Locale.ENGLISH));

Output is "3", but it should be "March".

It works well, when java.time.format.TextStyle.FULL is used:
System.out.println(Month.of(3).getDisplayName(TextStyle.FULL, Locale.ENGLISH));

Output is "March".

I think that java.time.format.TextStyle.FULL_STANDALONE works well for languages, where the output should be different, for example Czech:

System.out.println(Month.of(3).getDisplayName(TextStyle.FULL_STANDALONE, new Locale("cs")));

Output is "b��ezen", that is OK.

System.out.println(Month.of(3).getDisplayName(TextStyle.FULL, new Locale("cs")));

Output is "b��ezna", that is OK too.


REPRODUCIBILITY :
This bug can be reproduced always.


Comments
Issue fixed and addressed as part of https://bugs.openjdk.java.net/browse/JDK-8228477 hence, marking this bug as resolved.
11-03-2020

This is something that should work better. If the "full standalone" text does not exist for a locale, it should fallback to the "full" text (which is the intent of the CLDR data). I believe this affects both java.time and the older SimpleDateFormat.
01-01-2016

The attached test case executed on following versions: JDK 8 - Fail JDK 8u72 - Fail JDK 9ea b93 - Pass Output on JDK 8u : ------------------------- Full StandAlone Locale English: 3 Full Locale English: March Full StandAlone Locale CS: b?ezen Full Locale CS: b?ezna Output on JDK 9 ea: ---------------------------- Full StandAlone Locale English: March Full Locale English: March Full StandAlone Locale CS: b?ezen Full Locale CS: b?ezna
31-12-2015