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 _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
