[Thanks for the UTC/UT1/TAI summary, Paul.] In <9402072223.AA23255@bajoran.emba.uvm.edu>, wollman@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