time4j is not producing monotonic time in long since epoch

Question

I'm trying to produce monotonic time in long since epoch using time4j v5.6 using below test code

But output is not expected. Did I miss any initialization of the library? My objective is to produce monotonic time but don't need high precision as this can be executed on client side either linux/windows

import net.time4j.SystemClock;

import java.time.Instant;

public class MonotonicClock {
    public static void main(String[] args) {
        SystemClock systemClock = SystemClock.MONOTONIC;
        long t1 = systemClock.currentTimeInMicros() * 1000;
        boolean failed = false;
        for (int i = 0; i < 1000_000; i++) {
            long t2 = systemClock.currentTimeInMicros() * 1000;
            if (t2 < t1) {
                System.out.println(Instant.ofEpochSecond(0, t2) + "<" + Instant.ofEpochSecond(0, t1));
                failed = true;
            }
            t1 = t2;
        }

        if(failed) {
            System.err.println("Test Failed");
        }else {
            System.out.println("Test Passed");
        }
    }
}

What is the output you're getting and what are you expectations? — Pateman, Jun 03 '20 at 08:09
"Test Failed" output. I expected lib produce long timestamp which is same or greater than previous timestamp — sigirisetti, Jun 03 '20 at 08:12
Multiplying is not necessary. just to view timestamp output from Instant, may be there is a better for it — sigirisetti, Jun 03 '20 at 08:28
Instant.ofEpochSecond(0, t2) - second param is adjustment in nanos and can be full timestamp in nanos. that's ok. you may run sample class above and verify — sigirisetti, Jun 03 '20 at 08:34

score 2 · Answer 1 · answered Jun 03 '20 at 12:11

The Clock SystemClock.MONOTONIC is ultimately based on System.nanoTime(), see the source code. Latter one should be monotonic, and at least the handling of rare leap seconds is safely monotonic here, but it might happen to be not monotonic on some multi-core platforms where the JVM has difficulties to switch between the cores to form a consistent result of calling System.nanoTime(). See also the related SO-post with more useful links to the debate about the monotonicity of System.nanoTime().

A workaround could be to introduce a new constant SystemClock.MONOTONIC_ENFORCED which deploys a CAS-algorithm (based on java.util.concurrent.atomic.AtomicLong) to compare the actual nano-time with the previous one (with possible performance penalty). Let me know if you need this feature in the next release of Time4J.

Thanks for all the information in the post. If this doesn't penalize with lot of CPU cycles then it might be a worthy addition in the library. This will be useful in instances where events needs sequencing by time — sigirisetti, Jun 03 '20 at 13:16

time4j is not producing monotonic time in long since epoch

1 Answers1