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

[Daniel Fuchs]

On Thu, 10 Oct 2024 19:42:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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.

FWIW - when I updated the System UTC clock to get sub-milliseconds resolution from the OS I added this test:
https://github.com/openjdk/jdk/blob/master/test/jdk/java/time/test/java/time/TestClock_System.java

Maybe some similar technique could be used here. That is - take System.currentTimeMillis(), Take Instant.now(), take System.currentTimeMillis() again, and then verify that the instant lies between the two snapshots: greater or equal to the first, less or equal to the second. That should always be true (unless the UTC clock is adjusted by NTP). But you could hopefully detect that and retry if you observe that the second call to System.currentTimeMillis() has returned a value which is before the first call. 

If the difference between the two System::curentTimeMillis calls is too big, then if you wish you might want to try again too.

I believe this would provide a more robust test strategy.

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

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