RFR: JDK-8035099 LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect (original) (raw)

roger riggs roger.riggs at oracle.com
Mon Mar 17 14:51:30 UTC 2014

Hi,

This looks fine (not a Reviewer).

I'm checking on how to handle the change in TCK tests. The same question (and answer) applies to JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null

Roger

On 3/12/2014 6:48 AM, Stephen Colebourne wrote:

This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8035099

The implementation for LocalTime with(MILLIOFDAY, n) and LocalTime with(MICROOFDAY, n) fails to match the specification. LocalTime base = LocalTime.of(12, 30, 40, 987654321); LocalTime result = base.with(MILLIOFDAY, 0); expected: 00:00:00.000000000 was: 00:00:00.000654321 LocalTime result = base.with(MICROOFDAY, 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.

Proposed patch: https://gist.github.com/jodastephen/9057131 The patch includes no spec changes. The patch includes new TCK tests that are derived explicitly from the spec. I need a reviewer and a committer please. thanks Stephen

More information about the core-libs-dev mailing list