Re: [LEAPSECS] xntpd and adjtimex() handling of leap seconds

From: Markus Kuhn <>
Date: Mon, 01 Aug 2005 13:18:07 +0100

Poul-Henning Kamp wrote on 2005-08-01 11:26 UTC:
> The NTP kernel support will allow leapseconds on any midnight, but the
> NTP daemon is more strict.

Adding the missing test-override option to xntpd doesn't sound like a
really major engineering exercise.

I never liked the narrow-minded end-of-day leap flags in the current
adjtimex(). I hope this API will one day be replaced by a much simpler
and more generic one.

The sort of kernel clock driver API I have in mind uses three variables
to control leap seconds:

  time_t next_leap; /* marks the end of the next leap second
                          (traditionally next_leap == YYYY-{01,07}-01T00:00:00Z),
                          ignored if next_leap_len == 0 */

  int next_leap_len; /* 0: no next leap announced yet
                          +1: insert one second right before time == next_leap
                          -1: skip one second right before time == next_leap */

  int leap_adjustment_duration; /* number of seconds before the end of the next
                                   leap second, over which the time_t clock
                                   frequency will be adjusted to perform the
                                   phase step caused by the leap second.
                                   Recommended value:
                                     next_leap_duration == 1000 (UTS, 0.1% freq error)


  - simpler, actually reduces the lines of code in the kernel
  - more flexible, less likely to need modification due to future UTC policy changes
  - easier to test
  - API permits gentle UTS-style insertion of leap second that minimizes
    disruption to active real-time processes, though the existing
    very unfriendly non-monotonic kernel behaviour can still be
    requested by leap_adjustment_duration = 0.
  - [API permits natural extionsion for double leap-seconds through |next_leap_len| > 1
     (not required for the next ~60000 years though ;-]

Anything else is - in my eyes - an unwise choice on the policy versus
mechanism front.


Markus Kuhn, Computer Laboratory, University of Cambridge || CB3 0FD, Great Britain
Received on Mon Aug 01 2005 - 05:18:21 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT