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

DateTimeFormatter does not parse/accept the era.toString() result from MinguoEra/ThaiBuddhistEra

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b61

      Backports

        Description

           protected final DateTimeFormatter CHRONO_FORMAT = new
        DateTimeFormatterBuilder()
             .optionalStart()
             .appendChronologyId()
             .appendLiteral(' ')
             .optionalEnd()
             .optionalStart()
             .appendText(ChronoField.ERA, TextStyle.FULL) // FAILS HERE
             .appendLiteral(' ')
             .optionalEnd()
             .appendValue(ChronoField.YEAR_OF_ERA, 1, 9, SignStyle.NORMAL)
             .appendLiteral('-')
             .appendValue(ChronoField.MONTH_OF_YEAR, 1, 2, SignStyle.NEVER)
             .appendLiteral('-')
             .appendValue(ChronoField.DAY_OF_MONTH, 1, 2, SignStyle.NEVER)
             .toFormatter();

        will parse HijrahDate and JapaneseDate toString values, but not MinguoDate
        or ThaiBuddhistDate. It fails when trying to parse the era. I've also tried
        TextStyle.Short, appendPattern("G") and appendPattern("GGGG"). All fail in
        exactly the same place.

           CHRONO_FORMAT.parse(HijrahDate.of(1970, 02, 03).toString());
           CHRONO_FORMAT.parse(JapaneseDate.of(1970, 02, 03).toString())
           CHRONO_FORMAT.parse(MinguoDate.of(1970, 02, 03).toString());
           CHRONO_FORMAT.parse(ThaiBuddhistDate.of(1970, 02, 03).toString());

          Activity

          Hide
          sherman Xueming Shen added a comment -
          Era name returned from MingoDate/ThaiBuddhistDate's toString() doesn't match the name from the locale resource. The toString() return the name probably generated from their field name, which does not have the dot character(s), as found in the names from the resource, for example, for Minguo, it's ROC vs R.O.C and BE vs B.E. for Thai. (just try to format those "date" with the specified CHRONO_FORMAT.

          One way to fix this is to define the toString() to whatever we have from the resource, or use a dtf
          with appropriate style and root locale to get the names.

          The alternative is to patch the DTFBuilder to parse the toString() value specially.

          It is worth mentioned that "The toString() on ChronoLocalDate was never talked about as being something necessary to parse. It wasn't specced or designed for that.", as Stephen suggested. Though it is still desired the parse/accept the toString() result.
          Show
          sherman Xueming Shen added a comment - Era name returned from MingoDate/ThaiBuddhistDate's toString() doesn't match the name from the locale resource. The toString() return the name probably generated from their field name, which does not have the dot character(s), as found in the names from the resource, for example, for Minguo, it's ROC vs R.O.C and BE vs B.E. for Thai. (just try to format those "date" with the specified CHRONO_FORMAT. One way to fix this is to define the toString() to whatever we have from the resource, or use a dtf with appropriate style and root locale to get the names. The alternative is to patch the DTFBuilder to parse the toString() value specially. It is worth mentioned that "The toString() on ChronoLocalDate was never talked about as being something necessary to parse. It wasn't specced or designed for that.", as Stephen suggested. Though it is still desired the parse/accept the toString() result.
          Hide
          sherman Xueming Shen added a comment -
          As Stephen suggested, only parse and accept the era.toString in smart and lenient modes
          Show
          sherman Xueming Shen added a comment - As Stephen suggested, only parse and accept the era.toString in smart and lenient modes
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d071a5eab96d
          User: sherman
          Date: 2015-04-13 18:14:04 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d071a5eab96d User: sherman Date: 2015-04-13 18:14:04 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d071a5eab96d
          User: lana
          Date: 2015-04-23 01:41:22 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d071a5eab96d User: lana Date: 2015-04-23 01:41:22 +0000

            People

            • Assignee:
              sherman Xueming Shen
              Reporter:
              sherman Xueming Shen
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: