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 made changes -
          Assignee Roger Riggs [ rriggs ] Nadeesh Tv [ ntv ]
          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 made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Understanding Fix Understood [ 10001 ]
          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 ]
          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

            People

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

              Dates

              • Created:
                Updated:
                Resolved: