-
Bug
-
Resolution: Fixed
-
P4
-
9
-
b118
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 thatJDK-8148947 proposes pattern letter 'g' which is another example of this kind of format.
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
- relates to
-
JDK-8079628 java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value
- Resolved