[LEAPSECS] happy anniversary pips

Warner Losh imp at bsdimp.com
Wed Feb 12 11:03:52 EST 2014

On Feb 12, 2014, at 8:03 AM, Brooks Harris wrote:

> On 2014-02-12 04:36 AM, Greg Hennessy wrote:


>>>> Um, that is false. All linux kernels did not crash, in fact NONE of

>>>> mine did.


>>> "all" here was an overstatement, but the impact of the leap second

>>> should never be "your kernel crashes" even if your personal kernels

>>> didn't.


>> You should refrain from making inaccurate claims, it damages your

>> credibility.


>> The fact that the most recent leap second error didn't cause kernel

>> crashes but caused extra cpu cycles to be spent again lowers your

>> credibility.


>>> MP is hard, sure, but that's not the root cause of this issue.


>> The root cause of this issue was an error when stepping

>> a clock backwards? Why was the clock stepped backwards? To

>> comply with a POSIX requirement that does not match reality?


>> I submit that the proper fix is to update the spec

>> to match the fact that we now have days that are 86401

>> seconds long, now to eliminate leap seconds.




> There is nothing fundamentally wrong with UTC and Leap Seconds - the theory is sound, and the IERS does a fantastic job of keeping track of it. But there are difficulties with implementations for several reasons -


> A) The specifications and procedures regarding UTC are scattered over many documents and several standards bodies.


> B) There is no standardized, centralized, and *automated* way to obtain the UTC metadata (Leap Seconds table, announce signals, etc)

i'd add 'verified' or 'secure' (since many of the ways involve http:// urls) to this list.

> C) There are well know inadequacies with c and POSIX specs with regard to Leap Seconds which have percolated through the computer industry.


> D) Timezones are a horrendous mess, if somewhat mitigated now by IANA's administration of tz database.

E) Leap seconds are tied to observations of the earth's spin, rather than predicted years in advance. With only 6 months warning for leap seconds, this produces operational difficulties for many environments that have burdensome change control policies. Long term, we have the ability to predict out decades what the proper rate of leap seconds should be to keep things in sync over the long haul. One of the nice things about the Gregorian calendar is that it accepts errors of up to like 3 days (worst case) to keep the over all system simple (every 4 except 100 except 400) and on track for millennia. Leap seconds, as currently implemented, require too much "phone home" to keep things on track.

> "Eliminating Leap Seconds" doesn't begin to address the implementation difficulties. By itself it would likely make things (much) worse. Instead, all this passion could be directed at -


> A) Cleaning up and consolidating the UTC specs

and improving the spec. Currently, it works great for astronomers and other folks that need a cheap distribution of time within a second of UT who are fairly technical, but works less well for less technically situations (witness the number of places that get leap seconds wrong and don't care to fix it) and for less well connected environments.

A better analogy to the Gregorian calendar would be to have a leap second every 18 months for the next 100 years, with the next schedule to be published after 50 years for the hundred years after that. The problems with the Gregorian calendar on on the scale of thousands of years.

> B) Designing a good and modern "date and time metadata server"

Assuming internet connectivity may be problematic for some applications. ensuring that other distribution of time channels are augmented to include better leap data (GPS has current leap info, but no historical leap info, for example).

> C) Cleaning up the c and POSIX specs

The time guys were kicked out of the posix committee, so good luck on that one. :( And it isn't so much cleaning up the standard, which could be solved with some diplomacy, tact, etc. It is cleaning up all the code that's extant that assumes all days always have 86400 seconds, or that the formulas in the POSIX standard for converting broken up time into time_t are now invalid.

The C standard actually is fine, because it is too non-specific to be (a) useful and (b) cause problems.

> D) Clarifying timezone guidelines, including standardizing "international date line", "UTC offset", and methods of "Daylight instantiation"

This is really orthogonal to leap seconds.

> It took centurys for the Gregorian calendar to be accepted. Hopefully it won't take as long for society to start using UTC correctly.

Hopefully the UTC standard can evolve to match the needs of society better. Taking off my atomic time hat, there are a number of short comings to the standard which could make a time scale with leap seconds that's close to UTC, but through refinements offer better operational performance.

More information about the LEAPSECS mailing list