[LEAPSECS] The leap second, deep space and how we keep time -Brooks
imp at bsdimp.com
Wed Jan 28 11:55:37 EST 2015
> On Jan 28, 2015, at 2:33 AM, Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> Warner Losh schrieb:
>>> On Jan 27, 2015, at 7:18 PM, Steve Allen <sla at ucolick.org> wrote:
>>> On Tue 2015-01-27T21:41:17 +0000, Matsakis, Demetrios hath writ:
>>>> Equally unfortunate is that 30 servers in the NTP pool inserted a
>>>> leap second last Dec 31.
>>> There is no action that the ITU-R can take which will change this kind
>>> of misbehavior in these already-deployed systems.
>>> Therefore this is irrelevant to the activities which will happen at
>>> ITU-R WRC-15, and I don't think that misdirecting attention will help
>>> the ITU-R decide what to do.
>> One of the arguments against leap seconds are that they are hard to get right.
>> How many machines inserted an April 31st by mistake? Has an error like that
>> ever happened? No. Or more likely, has anybody thought it was Feb 29th in
>> a non-leap year? No. There have been some applications that mistakenly though
>> Y2K wasn’t a leap year. And there were some issues with the Zune music player.
>> And there was that unfortunate Feb 30th incident, but that was in a transition
>> to Gregorian… :)
>> By comparison, the list of mistaken leap second issues is legion… Isn’t that
>> relevant to the practicability of any standard under discussion? Or am I missing
>> your point?
> So similarly, if there are faulty DNS or DHCP servers around, should these services be abolished instead of fixing the source of the problem? ;-)
I think you’re making a false equivalency argument here. While DNS and DHCP can go awry, the frequency is quite a bit lower than bogus leap second announcements. There’s no single, systemic failure with DHCP or DNS like there is with a mistaken notion of leap seconds.
Fixing the source of the problem, leap seconds existing, though does sound like an excellent idea :)
More information about the LEAPSECS