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);
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.
More information about the tz