Time update causes problems (SF Issue)

[tanabi]

When the time on the machine is updated (via an ntp
daemon, Daylight Savings Time changes, or the admin
specifically setting it), the idletimes get COMPLETELY
out of whack, sometimes going into the completely
negative range.

For a fix, instead of relying on the absolute time of last
activity, should instead rely on a 'seconds since last
activity' counter, that should be updated whenever the
system clock changes. I realize it's a relatively large
operation, iterating through all the descriptors, but the
current behavior is both misleading and incorrect (even if
people really -are- time-travelling). Admins and MUF
authors don't realize that (especially at Daylight Savings
Time changes) the idle times will suddenly shoot
through the roof, or suddenly shoot through the floor.
And thus, they don't code to deal with those problems.

...

The value reported by time() should never be tweaked with by
a DST change. time() returns the number of seconds since
Midnight GMT, Jan 1st, 1970, no matter what timezone the
machine is in. If this value jumps it is only because the
sysadmin (or ntp) set the date manually, either because of
an incorrect attempt to set the system time around DST, or
because of system clock drift.

Having said that, yes this is in fact a bug, and FM has been
bitten by it at least twice now, due to system clock drift
corrections.

My proposal is to have a small test in the main loop that
checks if the current time is either less than the previous
checked time, or if the current time is more than the
select() timeout more than the previously recorded time. If
so, then it will do a one-time correction of the idle-times
to compensate by the difference.

...

Looking through the code here, the timequeue list would also
need to be updated. Affected files look to be:

timequeue.c
interface.c

Unless there's something I'm missing, I think this should do it.