JDK-8076528 : LocalTime.format() throws exception when FormatStyle is LONG or FULL
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2015-04-02
  • Updated: 2016-03-31
  • Resolved: 2016-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 9
9 b112Resolved
Related Reports
Relates :  
JDK-8085887 - java.time.format.FormatStyle.LONG or FULL causes unchecked exception
Description
Java: JDK8, JDK8 update or JDK 9
OS: windows 7, mac os x 10.9, OEL5

Compile and run attached program, JavaTimeTest.java.

In most cases, when FormatStyle of DateTimeFormatter is LONG or FULL, exception is thrown. Attached are the screen shots. 

On windows 7 zh_CN, if java.locale.providers is JRE, there will be output even FormatStyle is LONG or FULL, and no exception is thrown. But when I try in windows 7 en and ja, there is still the exception.

Attached are the screen shots.

---------------------------------------------------------------------------------------------------------------------
2015-05-04
When java.locale.providers is JRE, the default provider, in some locales, the format method works fine. For example, in locales zh_CN, zh_TW, ko_KR, th_TH, there is no exception thrown.

In most of the locales, there will be exception.

When java.locale.providers is CLDR or HOST, then in all the locales, there will be exception.

This happens in classes with 'time" like LocalDatetime, ZonedDateTime, etc. in java.time package.
Comments
Duplicate of 8085887
11-03-2016
Resolving as a duplicate of 8085887
11-03-2016
Printing a time nearly always requires the timezone to be known and available. The LocalDateTime does not have a field or value for the timezone. The program shows different behaviors in different locales because the locale specific pattern selected may or may not include a pattern letter than prints the timezone or zone offset. Those patterns including the letters: V, z, O, X, or, x require a timezone.
11-03-2016
In LocalDateTime, it behaves as the same. import java.time.*; import java.time.format.*; import java.util.Locale; public class LocalDateTimeTest { public static void main(String[] args) { LocalDateTime datetime = LocalDateTime.of(1958, 11, 20, 10, 18, 0); DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG); System.out.println(datetime.format(formatter)); } } Compile and run this problem in different locales, regardless of the OS. In some locales like zh_CN, zh_TW and ko_KR, it works fine, but in many other locales, there is the exception.
03-04-2015
I checked more locales, and find that, when java.locale.providers is JRE, the default provider, in some locales, the format method works fine. For example, in locales zh_CN, zh_TW, ko_KR, th_TH, there is no exception thrown. In most of the locales, there will be exception. When java.locale.providers is CLDR or HOST, then in all the locales, there will be exception.
03-04-2015
In my test, only in windows zh_CN, java.locale.providers=JRE, no exception is thrown. In all the other cases, there is the exception.
02-04-2015