[LEAPSECS] The Economist

[Dennis Ferguson]

On 17 Jan, 2012, at 23:03 , Markus Kuhn wrote:

> Will David L. Mills turn out to be the man who killed the leap second,

> by widely implementing it in a rather brutal fashion? He writes of his

> kernel time-keeping model in RFC 1589:

> 

>      If the value is TIME_INS, the kernel subtracts one

>      second from the system time immediately following second 23:59:59

>      and resets the clock status to TIME_OOP, in effect causing system

>      time to repeat second 59.

> 

> He seemed aware of the problem that this might not be particularly nice

> for applications, but failed to standardize and implement a much more

> benign way of navigating through the leap second, suggesting instead

> IMHO not very helpful hacks that might have been used to pass the

> 23:59:60 notation all the way to the application:


That's quite unfair.  Whatever you do is going to have side effects
having consequences for some applications, and leap seconds aren't the
only issue reliable applications may need to deal with.

I believe that if you are running applications which need to consume
UTC on systems whose UTC clock is being maintained by time synchronization
software then those applications need to be written to expect that
sometimes that clock will be wrong (occasionally seriously wrong) and
that the time synchronization software may need to make a step change
to fix it.  Reliable software must be written to survive that, to fix
up the errors they've already made to the extent possible (sometimes
it isn't possible; shit happens) and to continue on now that they have
a better estimate of UTC.  When the UTC-consuming software is written
like this making a step change is often the best (in addition to sometimes
the only) thing you can do; implementing the correction with a long slew
just delays the time when the applications will be receiving UTC with
the full accuracy that the time synchronization software knows it.
Software which is written like this (and I believe it must be if it
is to be reliable, leap seconds or not) will also survive a leap
implemented with a step just fine.  Also note that using a "right"
system clock, or one kept in some other ad hoc timescale, doesn't
change the requirements for reliable applications since even a "right"
clock can be wrong.

Of course there are also applications which couldn't give a damn
about UTC and just want to be able to reliably measure accurate time
intervals (in fact most of the software I write seems to fall into
this category, so I may be biased by this) and hence don't want to be
burdened with any of the problems of clock maintenance for the benefit
of the UTC consumers.  It isn't even unusual for the applications wanting
time intervals to be different parts of the same applications which
want UTC for other purposes.  Slewing adjustments for the benefit
of UTC consumers doesn't really fix the problems for time interval
applications either, since while that might allow the time to advance
continuously it does so by making the time intervals inaccurate, and that
still ignores the possibility of clock errors that are just too large to
slew away.  I hence believe that time interval applications and applications
which need UTC have fundamentally incompatible requirements (in real life,
if not in theory), so I use systems which provide a second clock maintained
by the system to provide reliable service to applications needing to measure
accurate time intervals.  The latter clock also leaps, but the leap is
implemented as an epoch adjustment, keeping the timescale itself continuous.

So for systems with software written to be reliable in the presence
of time synchronization software and possibly unreliable external sources
of time, I believe the behavior of RFC 1589 is not only benign but is in
fact preferable to most alternatives.  I may have other problems with RFC 1589,
but that isn't one of them.  And while I would admit that the above is
not "POSIX" (or is barely "POSIX", if you squint), I think the fact is that
if you want to run pure POSIX applications on your system reliably you will
dump the time synchronization software, set the system clock to your wrist
watch at boot time and then let the system clock free run on its local
oscillator until you reboot it, since that is the only thing which POSIX
defines support for.

Dennis Ferguson