:10 PM, Roger Riggs wrote:
Hi,
I created a Jira issue:
8307466 <https://bugs.openjdk.org/browse/JDK-8307466>
java.time.Instant Time difference calculation bug
The root cause of the bug is in the code that manages the
representation of Instant as seconds and nanoseconds.
The borrow/carry
Hi,
I created a Jira issue:
8307466 <https://bugs.openjdk.org/browse/JDK-8307466> java.time.Instant
Time difference calculation bug
The root cause of the bug is in the cod that manages the representation
of Instant as seconds and nanoseconds.
The borrow/carry logic between the secon
plusMillis(1);
> }
>
> This prints:
>
> 994
> 995
> 996
> 997
> 998
> 1000
> 1000
> 1001
> 1002
> 1003
>
> I'm fully prepared to accept that I've missed something, but at the moment
> I can't understand what that is.
>
> Rega
}
This prints:
994
995
996
997
998
1000
1000
1001
1002
1003
I'm fully prepared to accept that I've missed something, but at the moment I
can't understand what that is.
Regards,
Stuart
From: core-libs-dev On Behalf Of Roger Riggs
Sent: 03 May 2023 20:58
To: core-libs-dev@open
Hi,
The seconds and nano-seconds are computed separately.
The representation of Instant holds seconds and nanoseconds separately.
The computation is performed on the nano-seconds of the Instant and
truncated to milliseconds.
The value of 0.000999 becomes 0 when truncated to MILLIS.
Regards, R
Hello,
I believe I have discovered a bug in java.time. I've searched Jira and couldn't
find any existing similar issue.
Consider the following code:
var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
var t2 = Instant.parse("2023-05-03T10:00:01.000Z");
var t3 = Instant.pa
