Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8076528

LocalTime.format() throws exception when FormatStyle is LONG or FULL

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Duplicate
    • Affects Version/s: 8, 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Introduced In Version:
      8
    • Resolved In Build:
      b112
    • CPU:
      generic
    • OS:
      generic

      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.
      1. JavaTimeTest.java
        0.4 kB
        Yong Huang
      1. linux.png
        41 kB
      2. mac.png
        33 kB
      3. win7_zh_CN-CLDR-LONG.png
        47 kB
      4. win7_zh_CN-HOST-LONG.png
        58 kB
      5. windows7-en-LONG.png
        24 kB

        Issue Links

          Activity

          Hide
          yhuang Yong Huang added a comment -
          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.
          Show
          yhuang Yong Huang added a comment - 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.
          Hide
          yhuang Yong Huang added a comment -
          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.
          Show
          yhuang Yong Huang added a comment - 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.
          Hide
          yhuang Yong Huang added a comment -
          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.
          Show
          yhuang Yong Huang added a comment - 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.
          Hide
          rriggs Roger Riggs added a comment -
          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.
          Show
          rriggs Roger Riggs added a comment - 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.
          Hide
          rriggs Roger Riggs added a comment -
          Resolving as a duplicate of 8085887
          Show
          rriggs Roger Riggs added a comment - Resolving as a duplicate of 8085887
          Hide
          rriggs Roger Riggs added a comment -
          Duplicate of 8085887
          Show
          rriggs Roger Riggs added a comment - Duplicate of 8085887
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/28df1af8e872
          User: rriggs
          Date: 2016-03-16 17:24:39 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/28df1af8e872 User: rriggs Date: 2016-03-16 17:24:39 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/28df1af8e872
          User: lana
          Date: 2016-03-30 18:38:15 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/28df1af8e872 User: lana Date: 2016-03-30 18:38:15 +0000

            People

            • Assignee:
              rriggs Roger Riggs
              Reporter:
              yhuang Yong Huang
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: