| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8045632 | 8u25 | Roger Riggs | P3 | Resolved | Fixed | b01 |
| JDK-8040027 | 8u20 | Roger Riggs | P3 | Resolved | Fixed | b11 |
| JDK-8053860 | emb-8u26 | Roger Riggs | P3 | Resolved | Fixed | b17 |
The adjacent value parsing spec includes the phrase "If adjacent parsing is active, then parsing must match exactly the specified number of digits in both strict and lenient modes." in the method appendValue(TemporalField field, int width). Unfortunately, the spec is not correctly implemented when the first field in an adjacent parsing set is fixed width.
In strict mode, the first field in an adjacent parsing set uses its fixed width correctly producing the correct result. However it uses an inefficient double parse internally.
In lenient mode the first field in an adjacent parsing set is converted to be variable width producing the wrong result, and not conforming to the spec.
This can be noticed using a pattern of HHmm'9' which parses in strict mode but fails in lenient mode.
Discovered viaJDK-8031085.
In strict mode, the first field in an adjacent parsing set uses its fixed width correctly producing the correct result. However it uses an inefficient double parse internally.
In lenient mode the first field in an adjacent parsing set is converted to be variable width producing the wrong result, and not conforming to the spec.
This can be noticed using a pattern of HHmm'9' which parses in strict mode but fails in lenient mode.
Discovered via
- backported by
-
JDK-8040027 DateTimeFormatter fixed width adjacent value parsing does not match spec
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8031085 DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"
-
- Resolved
-