RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java now() to be more robust

[Roger Riggs]

On Thu, 10 Oct 2024 19:25:01 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> I don't think there is any way to meaningfully and reliably test the assertion that `Instant.now()` is the using the same clock as `Instant.now(Clock.systemUTC())` given the potential delays in execution of the two statements.
>> It might be possible to ignore well known delays due to gc or compilation by making sure the code is warmed up by repeating the test until the delta meets the .1 sec limit. If it was really a bug, the test would timeout after a couple of minutes. Putting a while loop around the body of the test would cover that.
>> I'd leave the code using `abs` alone to avoid exposing some other unanticipated change.
>
> I am keeping the timeout as 60 seconds. is this ok?
> 
>     @Test(timeOut=60000)
>     public void now() {
>         Instant expected, test;
>         long diff;
>         do {
>             expected = Instant.now(Clock.systemUTC());
>             test = Instant.now();
>             diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
>         } while( diff > 100 ); // retry if more than 0.1 sec
>     }

Yes, looks fine;  The normal JTREG timeout is 2 minutes. 60 seconds is fine for the testng timeout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1795993908