[LEAPSECS] happy anniversary pips

Brooks Harris brooks at edlmax.com
Wed Feb 12 10:03:33 EST 2014


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)

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.

"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
B) Designing a good and modern "date and time metadata server"
C) Cleaning up the c and POSIX specs
D) Clarifying timezone guidelines, including standardizing
"international date line", "UTC offset", and methods of "Daylight
instantiation"

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

-Brooks








More information about the LEAPSECS mailing list