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

DateTimeFormatter pattern letters 'A','n','N'

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Subcomponent:
    • Resolved In Build:
      b118

      Description

      The specification an implementation of these letters makes them significantly less useful than intended. This also means that 'A' does not match the intent of LDML/CLDR.

      In DateTimeFormatterBuilder, it can be seen that the definition varies by whether there is one or more than one letter:

      * A 1 appendValue(ChronoField.MILLI_OF_DAY)
      * A..A 2..n appendValue(ChronoField.MILLI_OF_DAY, n)
      * n 1 appendValue(ChronoField.NANO_OF_SECOND)
      * n..n 2..n appendValue(ChronoField.NANO_OF_SECOND, n)
      * N 1 appendValue(ChronoField.NANO_OF_DAY)
      * N..N 2..n appendValue(ChronoField.NANO_OF_DAY, n)

      Since these three fields are large and of varying width, this means that only the single letter patterns are useful. Specifying 'AA' will throw an exception unless the time is within the first 99 milliseconds of the day. In essence, the current code requires the user to put in enough pattern letters to handle the largest output value, which will then be zero-padded,

      The correct definition for these three fields is

      * A..A 1..n appendValue(ChronoField.MILLI_OF_DAY, n, 19, SignStyle.NORMAL)
      * n..n 1..n appendValue(ChronoField.NANO_OF_SECOND, n, 19, SignStyle.NORMAL)
      * N..N 1..n appendValue(ChronoField.NANO_OF_DAY, n, 19, SignStyle.NORMAL)

      This new definition will not change the definition of the single letters 'A', 'n' and 'N'. It will also not change the definition where there are enough letters to handle the maximum field value, eg 'nnnnnnnnn'. The only cases it changes are cases like 'AA', 'AAA' and 'AAAA' which are essentially unusable today. Since this is changing patterns are not currently usable, it seems reasonable to argue that it is a bug fix and not a major change to the spec. That said, I don't think this can be backported to Java 8.

      The user-facing documentation in `DateTimeFormatter` is vague enough that this change can be made. It would benefit from clarification that pattern letters 'A', 'n' and 'N' may have any number of letters and that the value will always output, zero padded if necessary.

      Note that JDK-8148947 proposes pattern letter 'g' which is another example of this kind of format.

        Issue Links

          Activity

          scolebourne Stephen Colebourne created issue -
          vtewari Vyom Tewari made changes -
          Field Original Value New Value
          Status New [ 10000 ] Open [ 1 ]
          dfuchs Daniel Fuchs made changes -
          Assignee Roger Riggs [ rriggs ]
          rriggs Roger Riggs made changes -
          Link This issue relates to JDK-8079628 [ JDK-8079628 ]
          rriggs Roger Riggs made changes -
          Labels 8-na
          ntv Nadeesh Tv (Inactive) made changes -
          Assignee Roger Riggs [ rriggs ] Nadeesh Tv [ ntv ]
          Hide
          ntv Nadeesh Tv (Inactive) added a comment -
          QQ and qq not specified as zero padded in http://unicode.org/reports/tr35/tr35-dates.html
          Should not DateTimeFormatter.ofPattern("qq").parse("2"); parse?
          (Currently it's failing because implemented as zero padded).
          or Am I confused with Zero padding concept?
          Similarly CLDR does not specify 'ee' as zero padding but java.time does.
          Show
          ntv Nadeesh Tv (Inactive) added a comment - QQ and qq not specified as zero padded in http://unicode.org/reports/tr35/tr35-dates.html Should not DateTimeFormatter.ofPattern("qq").parse("2"); parse? (Currently it's failing because implemented as zero padded). or Am I confused with Zero padding concept? Similarly CLDR does not specify 'ee' as zero padding but java.time does.
          Hide
          ntv Nadeesh Tv (Inactive) added a comment - - edited
          Please ignore my previous question.

          I understood the mistake . I was confused with zero padding.

          Therefore DateTimeFormatter.ofPattern("qq").parse("2"); should fail as expected since number of letter in '2' is less than the min width of 'qq'.
          Show
          ntv Nadeesh Tv (Inactive) added a comment - - edited Please ignore my previous question. I understood the mistake . I was confused with zero padding. Therefore DateTimeFormatter.ofPattern("qq").parse("2"); should fail as expected since number of letter in '2' is less than the min width of 'qq'.
          scolebourne Stephen Colebourne made changes -
          Description The specification an implementation of these letters makes them significantly less useful than intended. This also means that 'A' does not match the intent of LDML/CLDR.

          In DateTimeFormatterBuilder, it can be seen that the definition varies by whether there is one or more than one letter:

          * A 1 appendValue(ChronoField.MILLI_OF_DAY)
          * A..A 2..n appendValue(ChronoField.MILLI_OF_DAY, n)
          * n 1 appendValue(ChronoField.NANO_OF_SECOND)
          * n..n 2..n appendValue(ChronoField.NANO_OF_SECOND, n)
          * N 1 appendValue(ChronoField.NANO_OF_DAY)
          * N..N 2..n appendValue(ChronoField.NANO_OF_DAY, n)

          Since these three fields are large and of varying width, this means that only the single letter patterns are useful. Specifying 'AA' will throw an exception unless the time is within the first 99 milliseconds of the day. In essence, the current code requires the user to put in enough pattern letters to handle the largest output value, which will then be zero-padded,

          The correct definition for these three fields is

          * A..A 1..n appendValue(ChronoField.MILLI_OF_DAY, n, 19, SignStyle.NORMAL)
          * n..n 1..n appendValue(ChronoField.NANO_OF_SECOND, n, 19, SignStyle.NORMAL)
          * N..N 1..n appendValue(ChronoField.NANO_OF_DAY, n, 19, SignStyle.NORMAL)

          This new definition will not change the definition of the single letters 'A', 'n' and 'N'. It will also not change the definition where there are enough letters to handle the maximum field value, eg 'nnnnnnnnn'. The only cases it changes are cases like 'AA', 'AAA' and 'AAAA' which are essentially usable today. Since this is changing patterns are not currently usable, it seems reasonable to argue that it is a bug fix and not a major change to the spec. That said, I don't think this can be backported to Java 8.

          The user-facing documentation in `DateTimeFormatter` is vague enough that this change can be made. It would benefit from clarification that pattern letters 'A', 'n' and 'N' may have any number of letters and that the value will always output, zero padded if necessary.

          Note that JDK-8148947 proposes pattern letter 'g' which is another example of this kind of format.
          The specification an implementation of these letters makes them significantly less useful than intended. This also means that 'A' does not match the intent of LDML/CLDR.

          In DateTimeFormatterBuilder, it can be seen that the definition varies by whether there is one or more than one letter:

          * A 1 appendValue(ChronoField.MILLI_OF_DAY)
          * A..A 2..n appendValue(ChronoField.MILLI_OF_DAY, n)
          * n 1 appendValue(ChronoField.NANO_OF_SECOND)
          * n..n 2..n appendValue(ChronoField.NANO_OF_SECOND, n)
          * N 1 appendValue(ChronoField.NANO_OF_DAY)
          * N..N 2..n appendValue(ChronoField.NANO_OF_DAY, n)

          Since these three fields are large and of varying width, this means that only the single letter patterns are useful. Specifying 'AA' will throw an exception unless the time is within the first 99 milliseconds of the day. In essence, the current code requires the user to put in enough pattern letters to handle the largest output value, which will then be zero-padded,

          The correct definition for these three fields is

          * A..A 1..n appendValue(ChronoField.MILLI_OF_DAY, n, 19, SignStyle.NORMAL)
          * n..n 1..n appendValue(ChronoField.NANO_OF_SECOND, n, 19, SignStyle.NORMAL)
          * N..N 1..n appendValue(ChronoField.NANO_OF_DAY, n, 19, SignStyle.NORMAL)

          This new definition will not change the definition of the single letters 'A', 'n' and 'N'. It will also not change the definition where there are enough letters to handle the maximum field value, eg 'nnnnnnnnn'. The only cases it changes are cases like 'AA', 'AAA' and 'AAAA' which are essentially unusable today. Since this is changing patterns are not currently usable, it seems reasonable to argue that it is a bug fix and not a major change to the spec. That said, I don't think this can be backported to Java 8.

          The user-facing documentation in `DateTimeFormatter` is vague enough that this change can be made. It would benefit from clarification that pattern letters 'A', 'n' and 'N' may have any number of letters and that the value will always output, zero padded if necessary.

          Note that JDK-8148947 proposes pattern letter 'g' which is another example of this kind of format.
          ntv Nadeesh Tv (Inactive) made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Understanding Fix Understood [ 10001 ]
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b9760b7afe0d
          User: ntv
          Date: 2016-05-06 12:49:06 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b9760b7afe0d User: ntv Date: 2016-05-06 12:49:06 +0000
          hgupdate HG Updates made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolved In Build team [ 17324 ]
          Understanding Fix Understood [ 10001 ]
          Fix Version/s 9 [ 14949 ]
          Resolution Fixed [ 1 ]
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b9760b7afe0d
          User: lana
          Date: 2016-05-11 16:05:08 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b9760b7afe0d User: lana Date: 2016-05-11 16:05:08 +0000
          hgupdate HG Updates made changes -
          Resolved In Build team [ 17324 ] master [ 18256 ]
          hgupdate HG Updates made changes -
          Resolved In Build master [ 18256 ] b118 [ 17558 ]
          iris Iris Clark made changes -
          Labels 8-na 8-na jsr379-annex2-tbd
          iris Iris Clark made changes -
          Labels 8-na jsr379-annex2-tbd 8-na jsr379-annex1
          darcy Joe Darcy made changes -
          Link This issue csr of CCC-8148949 [ CCC-8148949 ]

            People

            • Assignee:
              ntv Nadeesh Tv (Inactive)
              Reporter:
              scolebourne Stephen Colebourne
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: