<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi,<br>
<br>
The PR with the fix is out for review:
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/pull/13846">https://github.com/openjdk/jdk/pull/13846</a><br>
<br>
Thanks for the issue report and followup.<br>
<br>
A possible workaround is to convert to millis and subtract, for
example,<br>
<br>
long diff = t2.toEpochMillis() - t1.toEpochMillis();<br>
<br>
Thank you, Roger<br>
<br>
<br>
<div class="moz-cite-prefix">On 5/4/23 12:10 PM, Roger Riggs wrote:<br>
</div>
<blockquote type="cite" cite="mid:71bd9a7f-6f85-fa6e-e11d-904d548e43d3@oracle.com">
Hi,<br>
<br>
I created a Jira issue: <br>
<a class="issue-link" data-issue-key="JDK-8307466" href="https://bugs.openjdk.org/browse/JDK-8307466" id="key-val" rel="5100136" moz-do-not-send="true">8307466</a>
java.time.Instant Time difference calculation bug<br>
<br>
The root cause of the bug is in the code that manages the
representation of Instant as seconds and nanoseconds.<br>
The borrow/carry logic between the seconds and nanoseconds is
suspect in Instant.until(Instant end, ChronoUnit unit).<br>
<br>
Thanks for the bug report, Roger<br>
<br>
<br>
<div class="moz-cite-prefix">On 5/3/23 4:47 PM, SHARPE, Stuart
(Commercial & Institutional CDIO) wrote:<br>
</div>
<blockquote type="cite" cite="mid:LO2P265MB33760D6EEC2CF1677F327C348A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM">
<pre class="moz-quote-pre" wrap="">Hi Roger,
Thanks for the reply.
I must admit I am struggling to understand your explanation. I can't see how the choice of internal representation would affect the result in this way. I also don't see anything in the JavaDoc that describes values being truncated prior to the calculation, and even if it did, the results are not consistent - if that was the expected behaviour, the results from my previous example would have been 1000 and 1001, would they not?
The part I quoted from the JavaDoc seems quite clear: it should return the number of whole units (millis in this case) between the two temporals. The number of milliseconds between 10:00:00.000999 and 10:00:01.000 is 999.001, which is 999 whole units.
I think the below illustration makes it clearer that there is something wrong. The output values are all what I would expect as per the JavaDoc apart from the result for t2 = 10:00:01.000.
var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
var t2 = Instant.parse("2023-05-03T10:00:00.995Z");
for(int i=0; i<10; i++) {
System.out.println(ChronoUnit.MILLIS.between(t1, t2));
t2 = t2.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.
Regards,
Stuart
From: core-libs-dev <a class="moz-txt-link-rfc2396E" href="mailto:core-libs-dev-retn@openjdk.org" moz-do-not-send="true"><core-libs-dev-retn@openjdk.org></a> On Behalf Of Roger Riggs
Sent: 03 May 2023 20:58
To: <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:core-libs-dev@openjdk.org" moz-do-not-send="true">core-libs-dev@openjdk.org</a>
Subject: Re: Time difference calculation bug
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, Roger
On 5/3/23 12:54 PM, SHARPE, Stuart (Commercial & Institutional CDIO) wrote:
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.parse("2023-05-03T10:00:01.001Z");
System.out.println(MILLIS.between(t1, t2));
System.out.println(MILLIS.between(t1, t3));
This prints:
1000
1000
Given that t3 is exactly one millisecond later than t2, it does not seem reasonable that they can both be 1000 milliseconds later than t1.
The JavaDoc for between() states "The calculation returns a whole number, representing the number of complete units between the two temporals."
Assuming I have understood this correctly, I think MILLIS.between(t1, t3) is correct but MILLIS.between(t1, t2) should return 999.
Regards
Stuart Sharpe
This communication and any attachments are confidential and intended solely for the addressee. If you are not the intended recipient please advise us immediately and delete it. Unless specifically stated in the message or otherwise indicated, you may not duplicate, redistribute or forward this message and any attachments are not intended for distribution to, or use by any person or entity in any jurisdiction or country where such distribution or use would be contrary to local law or regulation. NatWest Markets Plc, NatWest Markets N.V., NatWest Markets Securities Japan Limited and/or NatWest Markets Securities Inc. (collectively "NatWest Markets") accepts no responsibility for any changes made to this message after it was sent.
This communication, where prepared by the sales and trading desk or desk strategists, may be marketing material, desk strategy and/or trader commentary. It is not a product of the research department. This material may constitute an invitation to consider entering into a derivatives transaction under U.S. CFTC Regulations sections 1.71 and 23.605, where applicable, but is not a binding offer to buy/sell any financial instrument. The views of the author may differ from others at NatWest Markets.
Unless otherwise specifically indicated, the contents of this communication and its attachments are for information purposes only and should not be regarded as an offer or solicitation to buy or sell a product or service, confirmation of any transaction, a valuation, indicative price or an official statement. Trading desks may have a position or interest that is inconsistent with any views expressed in this message. In evaluating the information contained in this message, you should know that it could have been previously provided to other clients and/or internal NatWest Markets personnel, who could have already acted on it.
NatWest Markets cannot provide absolute assurances that all electronic communications (sent or received) are secure, error free, not corrupted, incomplete or virus free and/or that they will not be lost, mis-delivered, destroyed, delayed or intercepted/decrypted by others. Therefore NatWest Markets disclaims all liability with regards to electronic communications (and the contents therein) if they are corrupted, lost destroyed, delayed, incomplete, mis-delivered, intercepted, decrypted or otherwise misappropriated by others.
Any electronic communication that is conducted within or through NatWest Markets systems will be subject to being archived, monitored and produced to regulators and in litigation in accordance with NatWest Markets’ policy and local laws, rules and regulations. Unless expressly prohibited by local law, electronic communications may be archived in countries other than the country in which you are located, and may be treated in accordance with the laws and regulations of the country of each individual included in the entire chain.
Copyright © NatWest Markets Plc. All rights reserved. See <a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://www.nwm.com/disclaimer__;!!ACWV5N9M2RV99hQ!MLQn8Js2bYD_SSNi8IZD4ZmvsmT1g50e8lC1K3OnEP8KmswmXw2V7Yu8eXSxUP0yqpLlY0owu7LR6X2oZxrYueaalvFmtjI$" moz-do-not-send="true">https://urldefense.com/v3/__https://www.nwm.com/disclaimer__;!!ACWV5N9M2RV99hQ!MLQn8Js2bYD_SSNi8IZD4ZmvsmT1g50e8lC1K3OnEP8KmswmXw2V7Yu8eXSxUP0yqpLlY0owu7LR6X2oZxrYueaalvFmtjI$</a> for further risk disclosure (the agency arrangements referred to in the further risk disclosure between NatWest Markets Plc and NatWest Markets N.V. are not applicable to branches of NatWest Markets N.V.).
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>