[LEAPSECS] happy anniversary pips

[Brooks Harris]

On 2014-02-12 08:03 AM, Warner Losh wrote:

> 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.

Sure. All the related issues. You'd like to see many API's (XML, Binary 
XML, Soap, etc ) over many channels (Internet, private network, 
satellite, etc). If a core data set were designed that would be a start.

>

>> 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.


The IERS's ability to adjust UTC to +-0.9s of TAI is an incredible 
achievement. Its unpredictable, but that's fundamentally the nature of 
the beast. Lets deal with it. Its not hard to imagine some standardized 
way of stating how far in the future predictions are accurate and how 
far off they might likely be beyond that.


>

>> "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,

Yes.


>   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.

But its hard to fix in the absence of clear specification, so they 
really can't.

>

> 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.


Sure, but UTC handling, if flawed, is now embedded in the culture, like 
Gregorian calendar. Maybe the flaws can be fixed.


>

>> 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).


Yes. The metadata needs to be distributed over many APIs and channels.


>

>> 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.

Yes, but it all needs to be reengaged. Certainly many people are more 
attuned to the problems now.

>

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


Well, I mean the time-keeping APIs in general need to be cleaned up. 
POSIX says its relying on c. They might need clarification together. Or 
maybe its a wholly new spec from somewhere. W3C has tried with OWL, OMG 
with DTV, but they've tried to do it independently from POSIX and c, so 
it hasn't really worked out.

The flaws are embedded in the code and software culture. It will take 
years to fix all that, but it can't start until somebody fixes the 
standards.


>

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

> This is really orthogonal to leap seconds.

Yes, but its part of "civil time", which it what most are trying to 
achieve. Its a major stumbling block in implementation. It needs (much) 
better specification and/or guidelines.


>

>> 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.


Sure. Lets try.

-Brooks