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
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
