> On Jan 28, 2015, at 2:33 AM, Martin Burnicki <[email protected]> > wrote: > > Warner Losh schrieb: >> >>> On Jan 27, 2015, at 7:18 PM, Steve Allen <[email protected]> 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 :) Warner _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
