A few comments about the wiki notes. First ntpd is careful about ensuring that time always moves forward. It does this by adjusting the clock slew rather than jumping time forwards or backwards. When ntpd first starts up and the system clock is not set within 5 seconds relative to its ntp servers then ntpd will die with a log message rather than jump the time. Within about an hour of starting ntpd can have the system synchronized within a few milliseconds of its best server.
Some admins like to run ntpdate out of cron and force a time reset at regular intervals. It's never a good idea to force time jumps. It can case all kinds of trouble for databases, NFS, cryptography, process scheduler and even event systems written in perl. Most systems have a separate hardware clocks that is pretty accurate. OS time is typically synchronized with it at boot then runs independently of it. Some admins like to synch with hwclock out of cron. This is also a bad idea. On "wintel" type systems the hardware clock typically reports only down to seconds. This is much too rough for modern time keeping., Virtual machines add another whole layer of complexity to the picture. A vm will frequently have time jumps between time slices when it gets to run. Things that require real time behaviors probably should not be run in a vm. VM guests have to trust their host for an accurate representation of time. And all the issues that crop up above add another layer of complexity to accurate time keeping here There are very few good reasons for administrative clock adjustments. These days there are no good reasons based on simple calendrical causes. Soon even the dreaded leap second will be dealt with through math and lookup tables rather than clock adjustments. Nearly all other reasons to adjust the clock are political and organizational rather than technical. If we still want to deal with time sifts we have to detect them. When time jumps occur it is hard for a program to detect them. The only way that the program would know that time has changed is if it has two sources to compare. If such an event has been detected then it has to decide if there was a good administrative reason for the change or not. If the program decides to take action because it has detected a time change then it must have an array of logic to decide what special behaviors to apply for all of the various ways that the change could have occurred. Should it fire missed events? Should it recompute the offset for future events? what if the scale of the shift is large? What if the scale of the shift is tiny? What if time shifts occur frequently? What if they are noisy, crossing and recrossing the same point in time? We quickly get into pathological behaviors that either need to be accounted or ignored. Most developers who have cracked open this nut have eventually decided to leave well enough alone and have their system trust that the OS knows what time it is and that the admin had a "good reason" for mucking with the system time and leave it at that. Trying to correct for bad admin behavior is better done at the social layer than at the technical one. Just my thoughts. chris
