Path: utzoo!mnetor!uunet!mo
From: mo@uunet.UU.NET (Mike O'Dell)
Newsgroups: comp.bugs.4bsd
Subject: leap seconds
Message-ID: <5090@uunet.UU.NET>
Date: 13 Jan 88 03:58:41 GMT
Organization: UUNET Communications Services, Arlington, VA
Lines: 33

I just had a long conversation with Dave Mills about time ticking
and he is now of the opinion that jiggering the "real clock", i.e.,
the gicky the ticks away at some fairly regular rate is wrong.
The correct solution for synchronizing is to maintain an offset
between the "local real clock" and "global absolute time".  Note
that for high precision, this requires maintaining not only the
last known offset, but the 1st and 2nd derivatives so the drift
can be interpolated (to quite astonishing accuracies, it turns out).
In this scenario then, the offset reflects any leaping, not the
basal clock.  The "local apparent time" is formed by adding the
last known offset plus the interpolated drift term to the current
value of the real clock.  (Note that the interpolated value is a
function of the difference between the local real clock at the
last offset synchronization and its current value. This makes the
calculations a bit tricky if you want high precision.)

Therefore, the right place, I would argue, to put leaping is in
ctime().  I prefer to think of ctime() as a mapping between
external absolute time and the system's internal relative representation.
If you take this view, then it is clear that is where it goes.

Besides, I dunno how to set the clock WITHOUT leapseconds! If you
listen to WWV on a cheap plastic short-wave radio to set the time,
you get leap seconds!  So if you  ain't supposed to put them in,
you gotta manually subtract them!

Oh yes, I just realized it - the problem stems from using an epoc-relative
representation.  Absolute representations don't have the problem, or
at least push them so far into the past as to not matter.  For example,
	0400 UTC December 9, 1987 
doesn't suffer the bias - it's built-in!!

	-Mike