What should Timertask.scheduleAtFixedRate do if the clock changes?

Question

We want to run a task every 1000 seconds (say).

So we have

timer.scheduleAtFixedRate(task, delay, interval);

Mostly, this works fine. However, this is an embedded system and the user can change the real time clock. If they set it to a time in the past after we set up the timer, it seems the timer doesn't execute until the original real-time date/time. So if they set it back 3 days, the timer doesn't execute for 3 days :(

Is this permissible behaviour, or a defect in the Java library? The Oracle javadocs don't seem to mention anything about the dependency or not on the underlying value of the system clock.

If it's permissible, how do we spot this clock change and reschedule our timers?

Answer 1

Looking at the source of Timer for Java 1.7, it appears that is uses System.currentTimeMillis() to determine the next execution of a task.

However, looking at the source of ScheduledThreadPoolExecutor, it uses System.nanoTime().

Which means you won't see that behaviour if you use one in place of a Timer. To create one, use, for instance, Executors.newScheduledThreadPool().

Why you wouldn't see this behaviour is because of what the doc for System.nanoTime() says:

This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary origin time [emphasis mine].

As to whether this is a bug in Timer, maybe...

Note that unlike a ScheduledExecutorService, a Timer supports absolute time, and maybe this explains its use of System.currentTimeMillis(); also, Timer has been there since Java 1.3 while System.nanoTime() only appears in 1.5.

But a consequence of using System.currentTimeMillis() is that Timer is sensitive to the system date/time... And that is not documented in the javadoc.

Answer 2

It is reported here http://bugs.sun.com/view_bug.do?bug_id=4290274

Similarly, when the system clock is set to a later time, the task may be run multiple times without any delay to "catch up" the missed executions. Exactly this happens when the computer is set to standby/hibernate and the application is resumed (this is how I found out).

This behavior can also be seen in a Java debugger by suspending the timer thread and resuming it.