W3C home > Mailing lists > Public > public-sysapps@w3.org > December 2014

Task Scheduler and handling resetting the clock to an earlier date (presumably after it was set into the future accidentally)?

From: Andrew Sutherland <asutherland@asutherland.org>
Date: Wed, 31 Dec 2014 00:53:49 -0500
Message-Id: <1420005229.3755001.208204277.4300E4ED@webmail.messagingengine.com>
To: public-sysapps@w3.org
It's not clear this is a problem to be addressed by the Task Scheduler
API, but it seems like something there needs to be a solution for and
that the Task Scheduler spec should reference if it is handled by
another spec.

Here's an example situation:
- The device's clock gets set into the future for some reason, let's say
Jan 1, 2020
- The Task Scheduler API goes and clears out all all the alarms through
2020; users of the API are unable to schedule anything in the past.
- ServiceWorkers that do some kind of periodic thing schedule an event
for 1 day in the future, so Jan 2, 2020.
- The device's clock is reset to the correct date, but now the app's
ServiceWorker will not be launched until many, many years in the future.

While one would hope that things like this don't happen, on some
development devices with firmare in flux, clock problems have
unfortunately been a real thing.

Broadly speaking, the options would be to have the API be resilient to
having an incorrect device time or to have mechanisms for recovering
from time issues in a timely fashion.  The former seems difficult for
the API to address, especially given that there are complex UI/server
interactions that might be required ("have you really not used this
device in 3 years?!")

Some recovery options:

- Require the Task Scheduler (or other spec/API) to persist enough state
so that it can detect apparent jumps backward in time and generate a
notification to all appropriately registered service workers (although
not all at the same time).  A notification could also be generated if
time jumped forward, but since existing events should probably already
fire in that case, there is much less benefit.

- Have the task scheduler support some type of non-precise scheduling
mechanism that ignores the wall clock time and depends on observable
elapsed device time.  So a ServiceWorker would say "call me at least
every N hours" and the task scheduler would use interval timers in
conjunction with a state that indicates there are approximately X
seconds before it should fire.  The state would be persisted
periodically.  This would allow apps to have a paranoia backup.  I don't
think this is actually a good idea, but it's an option.  (As an
optimization the implementation could also track wall-clock time to
avoid wasteful polling/saving.  But the idea would be that a device that
was rebooted every hour and lost its clock state on the hour would still
eventually trigger the worker.)

Received on Wednesday, 31 December 2014 05:54:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 16:04:47 UTC