[LEAPSECS] BBC article

[Dennis Ferguson]

On 17 Nov, 2011, at 09:37 , Steve Allen wrote:

> On Thu 2011-11-17T06:49:59 -0800, Steve Allen hath writ:

>> It works like the javascript on this page

>> http://www.ucolick.org/~sla/leapsecs/epochtime.html

>> which risks restarting some totally pedantic and legalistic

>> arguments of the sort we're now seeing about POSIX and C time

>> because the standards documents are self-inconsistent in the

>> presence of the reality that UTC has had leap seconds.

> 

> At the bottom of that page is a note pointing out that IEEE 1003.1

> (POSIX) and IEEE 1588 (PTP) are two standards from one organization

> which require two different counts of elapsed seconds for systems that

> use them.

> 

> This is a fundamental problem.


The original version of IEEE 1588, which was then imagined to be a way
for networks of consumer equipment to synchronize their clocks, did in
fact use POSIX timestamps, as do a number of other IEEE standards.  I
forget what they planned for leap seconds, so it wasn't impressive enough
to capture my attention.

The much more recent revision of IEEE 1588 changed this.  By then that
committee had become much more interested in solving the problems that
telecommunications operators were causing themselves by replacing
finely-clocked T1's and E1's to (often mobile base station) terminals, which
could provide a frequency reference for the terminal as well as a bit pipe,
with cheap-crystal-clocked ethernet circuits which were useless for anything
other than moving bits cheaply.  IEEE 1588 became the solution for providing
the now-missing frequency reference, and there are a growing number of examples
to demonstrate that if your primary interest is precise time intervals rather
than precise (civil?) time (the satellite navigation services are similar) you
deal with leap seconds by making up a whole new time scale which doesn't have
them, treating the what-time-it-is problem as either a side show or as someone
else's problem.  I think IEEE 1588 has ended up in the latter camp.

In any case, the requirements for the problem IEEE 1588 timestamps were intended
to solve morphed into something which were not the same as the requirements for
the problem POSIX timestamps were intended to solve, so it isn't surprising they
ended up with different choices.  There is a significant amount of evidence that
there is no one currently-existing timescale which solves both these problems well
(if there were you wouldn't have every new service which does some form of time
distribution rolling its own).

Dennis Ferguson