I wrote:

>> There's not much one can do once things have gone that far.  As
>> someone else is fond of saying, ``don't do that, then''.

Which I did not mean to be a flame and I'm sorry if it was taken that
way.  I was intending to convey something like "Well, running a system
with the hardware clock misconfigured by several *hours* is a
configuration error, how much pain should we go through to lessen the
pain of fixing this configuration error every time the machine
reboots?", instead of (say) letting the user fix things up and reboot,
once, with the correct time.

I'm still not really clear if Dennis Ferguson's original proposal was
intended to address such a situation, or if it's intended to (for
example) behave robustly when someone is calling settimeofday() on an
continual basis, to tweak the system clock into agreement with
UTC. (Like, oh, the HP-UX adjtime daemon is reported to do), or by
just calling settimeofday() from a cron script, -- as, oh, the default
use of /usr/sbin/rdate does, for example.  I still have yet to hear
anyone a case that the latter causes signficnt problems. I don't do
it, so I don't know if it does.

Dick Gabriel has a mildy-famous article that's relevant here,
whichever stance one takes on settimeofday() vs timers.  See

  http://www.ai.mit.edu/articles/good-news/subsection3.2.1.html

which argues for a simple design, leaving exceptional cases to the
user.  In the scenario Dennis describes, fixing the misconfigured
clock and rebooting seems to fit that. *If* one wants the kernel to
address that problemt, then the solution Dennis describes seems to
fit reasonalby well, also.  But it doesn't address what I've
claimed is an underlying problem, namely that real-time timer
facilites are used both to sleeup until a given *real* time, and 
to implement rate-controlled serviecs. 

I think it's close to axiomatic that a signle timer implementation
that *fails* to pass that distinction across its interface cannot do
the right thing in both casess -- Even if an implemetnation that does
close to the "right ting" in both cases is little more pain than one
that doesn't, given the relevant information.

So I'm saying, "can we extend the interface so that we can do the
right thing?"  (ignoring, for now, what the 'right thing' or "real
time" *is*, if the system clock is being stepped frequently).

Havard  Eidnes <Havard.Eidnes@runit.sintef.no> replies:

>I disagree.  I do not think there is any tradition for saying "do not
>use settimeofday() except right after boot".  Certainly the manual
>page for settimeofday() does not make any such warning or that setting
>the time of day can have such unfortunate side-effects that timers
>will "stop firing for an extended period of time".

>Rather, I would claim that the application wanting to sleep until a
>specific point in (real) time should check the time with
>gettimeofday() when it is woken up again.  There is no guarantee
>that the clock of a given machine will actually be correct at all
>times,

I agree there is no strong *guarantee*, not at all.  All I was trying
to point out, is that if one is going to introduce large,
discontinuous jumps into the system's 'real-time' clock, then
*something* loses.  One can pick one or other case as the ``common
case'' for the kernel to get right, and punt on the other.

Dennis Ferguson said, clearly and explicitly, that he was happy to fix
the problem he considered important and "damage" cron.  (And, if I
understood his proposed solution, using what in some ways is a "New
Jersey" style approach, rather than an "MIT" one:))  Otherwise I'd
be quite happy with it.

I think I'm saying I'd sooner keep cron and "at" and "leave" working,
if it comes down to personal preferences --  which I don't think
it should, at all.