Hi,
On 11/04/2020 00:53, David Holmes wrote:
Update:
It's a holiday weekend so I can't dig into this right now but we tried
using a high-precision clock source for systemUTC() in the past but it
didn't work because systemUTC() and currentTimeMillis() have to use
the same time base, and currentTimeMillis() has to use gettimeofday().
I thought this cross-dependency was documented somewhere but can't
find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME)
actually have the same time characteristics wrt. wall-clock time then
changing both as suggested may indeed work.
Just to emphasize David's comment: System::currentTimeMillis() and
Clock::systemUTC() should use the same time source: if they don't - then
some tests will fail, and because it can be tricky to assert things
in tests, they might (and probably will) fail only intermittently.
I'm probably the culprit here, I added those tests when I upgraded
Clock::systemUTC() to report sub millisecond granularity [1] - as was
available in the underlying clock that System::currentTimeMillis()
already used.
However, I think I would be disturbed if System::currentTimeMillis()
and Clock::systemUTC() were using different clocks and could
report a different notion of time (by drifting away from each other).
best regards,
-- daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8068730
