In message <[EMAIL PROTECTED]>, "Tom Van Baak" writes: >This meant that Windows >timekeeping worked pretty much the same as any >BIOS, PDA, wristwatch, wall clock, desk clock, >car clock, thermostat, or VCR; namely, it keeps >adequate time and you re-set it when it's off by >too much. Windows does have timezone and >programmed DST support for the functions that >report local time.
There is an open issue according to M$: http://support.microsoft.com/default.aspx?scid=kb;en-us;246145 In the earlier version, there was a delay in insertion of a leap second through a multi-tiered environment, although this delay did not occur in every instance. The TimeServ utility currently does not schedule the insertion for the exact moment at midnight. Instead, TimeServ inserts the second at the first synchronization after the source time has adjusted, and then logs the event. In a tiered environment, the leap second may be inserted in the following order: 1. On the master server. 2. When any primary machines request the time from the master. 3. When any secondary machines request the time from a primary. For types that warn of a coming leap second, the TimeServ utility optimizes the synchronization time to be shortly after the moment of leap second insertion. The synchronization occurs with certain allowances for randomization in order to spread potential overloading at individual servers, and delays due to tiered structure. The TimeServ utility tries to resynchronize all machines within 15 minutes of the leap second. As I read this, leapseconds sort of trickle out from the timeservers to the client in whatever time it takes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
