how does timer: deal with real-time clock changes?

[Ulf Wiger]

On Thu, 14 Mar 2002, Matthias Lang wrote:

>Aside: it is fundamentally wrong to combine wall time with the
>  base used for time interval measurements if you cannot
>  guarantee that wall time is continuous. No system that allows
>  manual time adjustment can guarantee that. Smoothing out now()
>  is a hack which we're probably stuck with because of existing
>  code which relies on now() being continuous, including the
>  timer() module.

I think the erlang:now() time (properly adjusted) can be
considered to relate to actual system time much like UTC time
relates to Daylight Savings Time. It's much easier to write
time-dependent programs if you can safely assume that time will
not start arbitrarily jumping back and forth.

The AXD 301 approach is to always keep the operating system in
UTC Time, and set the TZ environment variable for the Erlang VM,
so that we can support local time in logs and other presentation
formats. We dismissed the Solaris approach of patching the OS
everytime the rules for Daylight Savings Time change (which they
constantly do.) Instead we let the operator enter the appropriate
rules for local time through a web interface.

We also keep track of any discrepancy between erlang:now() and
the system clock. Since erlang:now() will adjust with +/- 1%,
small discrepancies will resolve themselves, but large ones will
take too long. Thus, we generate an alarm if the difference is
too great, asking the operator to restart each CPU, one by one.
The "floating" erlang:now() will ensure that the system doesn't
freeze or simply die, but we don't know how to hide the
discrepancy from the operator.

All this will basically only happen if the operator has messed
with things he/she should have left alone. The system clock is
set first with rdate (against a known time reference) at system
startup, and then fine-tuned with NTP.

We still have to deal with the fact that operators want to
schedule operations in local time, which means that the scheduled
time could potentially be skipped completely (e.g. if local time
jumps from 2am to 3am, and an operation is scheduled for 2.30).
One can of course warn the operator if the scheduled operation
falls inside such an interval, but then the operator could of
course schedule the operation first, and then change the rules
for DST!

It would surely be wonderful if someone could invent a simple and
elegant solution for all this.


/Uffe