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.