[time-nuts] Gnu C Time Libraries LeapSecond support
Poul-Henning Kamp
phk at phk.freebsd.dk
Fri Jul 22 15:31:09 EDT 2005
In message <002c01c58ef2$567d28c0$5e12f204 at computer>, "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
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the time-nuts
mailing list