leap seconds

Bradley White bww+ at transarc.com
Mon Feb 7 23:05:34 UTC 1994


[Thanks for the UTC/UT1/TAI summary, Paul.]

In <9402072223.AA23255 at bajoran.emba.uvm.edu>, wollman at emba.uvm.edu writes:
> Currently, we have a situation where there is a 17-second discrepancy
> between the time as displayed certain other NTP-running systems, as
> compared to ours, which quantity really doesn't suggest anything to
> someone trying to figure out what's going on.  If we can arrange
> things so that the discrepancy works out ot be exactly |TAI-UTC|, then
> time-savvy users can then say, ``Oh!  Obviously, (system X) doesn't
> handle leap seconds!'' and then stop sending in bug reports about it.
> 
> Then all I have to do is figure out what NTP expects the kernel time to do
> around leap seconds, and we should be set!

Any system that runs with ``REDO=right_*'', and which therefore wants to
continue to tick normally over leap seconds, needs to do a little bit of
work to generate NTP-style timestamps.  That is, NTP-style timestamps are
discontinuous over leaps, while ``REDO=right_*'' time_t's are continuous.

Recent incantations of the `tz' package provide the time2posix() function
to help in mapping between these two formats.  For example, in the (old,
version-1) NTP code, you need to change ...

	stampp->int_part = htonl(tvp->tv_sec + JAN_1970);
to
	stampp->int_part = htonl(time2posix(tvp->tv_sec) + JAN_1970);

I haven't looked at the (new, version-3) XNTP code, but I imagine the
change needed there is just as trivial.

After that, you will chime NTP harmoniously with the rest of the world,
*and*, you will sail smoothly through leap events without the jitter or
confusion suffered by your NTP peers.

Bradley



More information about the tz mailing list