CODEWITHSUNDEEP
javaandroid
Gogu CelMare
Gogu CelMare

Reputation: 823

What happens with running timers when a system time is changed?

What happens with running timers when a system time is changed?

I have an android application and I use handler.postDelayed(Runnable,interval) to post a Runnable to be called (the run() method) at the end of the interval.

The question I have is: What happens if the underlying system time is changed externally? My impression is that the posting still happens but at the time of system time change the countdown starts again... Can anybody shade some light here?

Does the behavior change if the time change is forwards or backwards?

Upvotes: 2

Views: 1696

Answers (2)

Baoyang
Baoyang

Reputation: 36

First,you should know Handler is based on SystemClock.uptimeMillis(). Handlers sendMessageXXX() methods such as sendMessageDelayed、sendEmptyMessage all use the method below internal:

//calcute the milliseconds we hope to handle the message since the system was booted
sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis)

Then,the time interval value SystemClock.uptimeMillis() + delayMillis will be kept into Message's field when,and we put the message into the MessageQueue waiting for Looper to poll out it.

While the looper gets the next message from the queue,it will compare SystemClock.uptimeMillis() with msg.when to judge whether the message is ready.If the next message isnt ready,it will set a timeout to wake up until the msg is ready.

Second,you confuse SystemClock.uptimeMillis() with System.currentTimeMillis().Below is part of the documentation of SystemClock which explains the two concepts:

  • SystemClock.uptimeMillis() is counted in milliseconds since the system was booted. This clock stops when the system enters deep sleep (CPU off, display dark, device waiting for external input), but is not affected by clock scaling, idle, or other power saving mechanisms. This is the basis for most interval timing such as Thread.sleep(millls), Object.wait(millis), and System.nanoTime(). This clock is guaranteed to be monotonic, and is suitable for interval timing when the interval does not span device sleep.
  • System.currentTimeMillis() is the standard "wall" clock (time and date) expressing milliseconds since the epoch. The wall clock can be set by the user or the phone network (see setCurrentTimeMillis(long)), so the time may jump backwards or forwards unpredictably. This clock should only be used when correspondence with real-world dates and times is important, such as in a calendar or alarm clock application. Interval or elapsed time measurements should use a different clock. If you are using System.currentTimeMillis(), consider listening to the ACTION_TIME_TICK, ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED Intent broadcasts to find out when the time changes.

Upvotes: 1

Dibzmania
Dibzmania

Reputation: 2014

No it doesn't matter. If you dig around the code, the delay is provided by the following mechanism - 

SystemClock.uptimeMillis() + delayMillis

So it is purely relative. And changing of system time has no effect on it

Upvotes: 1

Related Questions