JDK-8035099 : LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-02-17
  • Updated: 2014-08-11
  • Resolved: 2014-04-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u20 b11Fixed 9Fixed
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.

affected test: api/java_time/tck/java/time/index_TCKLocalTime

Attaching patch for IP reasons

Patch updated https://gist.github.com/jodastephen/9057131

I don't recall the test being anywhere near that slow for me. I am happy for the patch to be edited in the obvious way.

The tests need to run in 10-15 seconds. The near exhaustive testing of values for nanoseconds forces the test to run too long.

Patch to fix and test this: https://gist.github.com/jodastephen/9057131 I suspect that the tests will need to be non-tck for the backport.