18 sec

[Paul Eggert]

   Date: Tue, 29 Mar 1994 14:48:27 -0500
   From: Garrett Wollman <wollman at adrastea.lcs.mit.edu>

   3) The NTP code ``handles'' leap seconds by turning the clock
   back when they happen.

That is a portability bug in the NTP code.  The code should be fixed
to see whether the underlying system knows about a leap second, and if
so, the NTP code should not muck with the system clock when that leap
second occurs.  It is easy to see whether the underlying system knows
about a particular leap second simply by using the standard gmtime
function.  E.g.:

	int
	knows_about_leap_second_inserted_at (time_t t)
	{
		return gmtime(&t)->tm_sec == 60;
	}

Wollman also writes:

   1) The timezone database does not reflect the fact that the first
   time step, in going from GMT (pre-1972) to UTC (1972 to present)
   was actually 10 seconds, and not just one like all subsequent leap
   seconds.

This oversimplifies the actual situation.  I've discussed this before
on the tz list; here is a slightly revised version of my thoughts for
those who haven't seen them before.

The basic, underlying problem is that the Posix standard defines the
time origin to be 1970-01-01 00:00:00 UTC.  But there is no such
time, because UTC was not established until 1972-01-01 00:00:00.
In order to figure out what to do about this, we must reconcile
this inconsistency between the time standard and the Posix standard.

UTC obeys two constraints: (1) |UTC-TAI| is an integer, (2) |UT1-UTC| < 0.9 s.
TAI is International Atomic Time, our best approximation to ``real'' time.
UT1 is astronomical time, our best approximation to Earth's rotation angle;
it was the basis for civil time between 1956 and 1972.
 
When UTC was established in 1972, UTC-TAI was set to be exactly 10 s.
This explains why UTC-TAI will be 29 s after 1994-06-30, even though
the leapseconds file lists only 19 seconds inserted by then.
 
Why was UTC-TAI initially 10 s and not zero?  Because UTC is designed
to track UT1 within 0.9 s, and UT1-TAI was approximately 10 s at the
time UTC was established.  And _this_ is because TAI was set
approximately equal to UT1 on 1958-01-01, and the two scales had
diverged by 10 s in 1970.
 
Had UTC existed on 1970-01-01 under the current rules, it would have
differed from TAI by either 7 or 8 s.  The ambiguity is because of the
slop in UTC's constraint (2).  In practice, this ambiguity is resolved
by a committee of the International Earth Rotation Service, but that
won't help us for times before 1972.

I see three possible fixes to the tz code, none of which have generated
much enthusiasm:
 
        A.  Leave the leapseconds file alone, and pretend that civil
        time equaled TAI + 10 s before 1972.  Add a 10 s correction to
        the code that converts between the tz package's times and NTP.
        This introduces an error of 2 or 3 s for times around 1970.
 
        B.  Invent some leap seconds for the period between 1970 and
        1972, as if UTC had been in effect then.  This lies about UTC
        but repairs the 2 or 3 s error.  The conversion correction
        would be correspondingly reduced, to 7 or 8 s.
 
        C.  Invent some leap seconds for the period between 1955-07-01
        and 1972.  This is the same as (2) but reduces errors for old
        times.  We can't go back before 1955-07-01 because atomic time
        didn't exist before then.  A problem with (C) is that some
        hosts don't allow negative time_t values.
 
(A) is easiest and in a sense is the most honest, but it has one major
problem: it leaves us 2 or 3 s away from our goal of having time_t
values that represent ``the number of seconds since 1970-01-01 00:00:00 GMT'',
the way Unix was originally intended.