| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8038753 | 9 | Stephen Colebourne | P4 | Resolved | Fixed | b08 |
| JDK-8045630 | 8u25 | Stephen Colebourne | P4 | Resolved | Fixed | b01 |
| JDK-8053858 | emb-8u26 | Stephen Colebourne | P4 | Resolved | Fixed | b17 |
The implementation for LocalTime with(MILLI_OF_DAY, n) and LocalTime with(MICRO_OF_DAY, n) fails to match the specification.
LocalTime base = LocalTime.of(12, 30, 40, 987654321);
LocalTime result = base.with(MILLI_OF_DAY, 0);
expected: 00:00:00.000000000
was: 00:00:00.000654321
LocalTime result = base.with(MICRO_OF_DAY, 0);
expected: 00:00:00.000000000
was: 00:00:00.000000321
The spec is clear in both cases - "This completely replaces the time and is equivalent to using {@link #ofNanoOfDay(long)}", thus this is clearly a bug.
The bug fix should be backported to JDK 8u.
LocalTime base = LocalTime.of(12, 30, 40, 987654321);
LocalTime result = base.with(MILLI_OF_DAY, 0);
expected: 00:00:00.000000000
was: 00:00:00.000654321
LocalTime result = base.with(MICRO_OF_DAY, 0);
expected: 00:00:00.000000000
was: 00:00:00.000000321
The spec is clear in both cases - "This completely replaces the time and is equivalent to using {@link #ofNanoOfDay(long)}", thus this is clearly a bug.
The bug fix should be backported to JDK 8u.
- backported by
-
JDK-8038753 LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-