On 2014-02-12 07:47 AM, Warner Losh wrote:
The linux kernel has been touted by some of its proponents as the most tested and verified kernel around. Some may quibble with this characterization, but if not the most, certainly one of the most. And even so, this problem with leap seconds managed to escape into released kernels. If that happened, here, what hope is there for other, less well tested systems.
In my industry we have a timing protocol casually referred to as "timecode", the latest specification is called "ST 12". There's a reasonably good explanation of it at Wikipedia - http://en.wikipedia.org/wiki/SMPTE_timecode.
The original designs of this predate the c and POSIX specs, tracing their heritage to IRIG timecode http://en.wikipedia.org/wiki/IRIG_timecode.
In the early years of industry deployment it was pretty unreliable. It took years for venders, both hardware and software, to learn how to do it interoperablly. As things progressed, SMPTE revised and refined the specification and eventually everybody was on the same page. It was really 10 years before it all settled down, or "matured".
The implementation of UTC in computers spans many standards bodies across many disciplines so its way more difficult in that respect. Its going to take a while.
I think the "kill Leap Seconds" call as an unfortunate diversion from concentrating efforts to clarify usage.
In my experience in standards bodies the conversation and resources are driven by venders who in turn are presumably responding to their customer's requests but too often the user's opinions get lost in translation.
The LEAP_SECS list seems populated mostly by computer "users" (sophisticated users), rather than "manufacturers" or "venders". As a group you all could probably have some influence.
-Brooks _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
