On Fri, Dec 23, 2016 at 8:37 AM, John Sauter <john_sau...@systemeyescomputerstore.com> wrote: > On Thu, 2016-12-22 at 21:50 -0700, Warner Losh wrote: >> >> These are the reasons I hate leap seconds: they are of dubious value >> and cause all kinds of havoc because nobody expects them to work, and >> the programming standards are written as if they don't exist. >> >> Warner > > Dubious value: leap seconds cause UTC, and thus civil time, to track > the sun. I don't regard that value as dubious.
So do time zones. People that care about DUT1 can get it over the internet these days. UTC isn't precise enough for them anyway. There are some folks with legacy gear that can't easily be changed (mostly telescopes), so I feel for them since often they have hired someone to build the telescope, maybe years ago, and changing now would be quite costly. The error that leap seconds correct is ~21 parts per billion (today). Leap days correct an error of ~1.1%, so the comparison isn't too apt. The value is mostly theoretical, but they won't be around forever since the quadratic acceleration of leap seconds will mean in the future we'll need to come up with a better way to cope. Leap years are still good for maybe 10k years before we have to adjust. Leap seconds are unlikely to be viable in a thousand years. > Cause all kinds of havoc because nobody expects them to work: > expectations can be changed by fixing the applications so that they do > work. Fixing applications takes time, and expectations will lag behind > the fixes, but given time the problem is not unsolvable. The problem is almost unsolvable. Changing expectations is impossible. Leap seconds are too flakey to teach once in programming class. They are too unpredictable to provision long enough in advance for the life of a system (unlike leap days). They are just a second, so nobody allocates resources to fix issues: they just live with the results. There's been no sign that things have improved in the last 15 years since I started working in the field, so while I admire your optimism, I'm to jaded to share it. Until you can address the systemic bias against leap seconds in the world, they will continue to be the bastard child of time keeping, with only the most pedantic getting them right. > The programming standards are written as if they don't exist: no longer > completely true--POSIX, for example, implicitly acknowledges their > existence before requiring applications to pretend they don't exist. > Standards follow practice: when applications routinely handle leap > seconds correctly, their techniques will be incorporated into > standards. POSIX time_t says they don't exist. Therefore, they don't exist. There is some lip-service to leap seconds in struct tm, but until time_t can cope, the standard is hopelessly broken. The number of programs that use time_t is huge, and almost none of them get leap seconds right (the one that do have to use extra data not covered by the standard to get it right). The POSIX committee is actively hostile to changing this state of affairs and has made the engineering decision that it's just a second, and people don't get it right, so they simplify the problem by assuming they don't exists, or if they do they are handled outside of the standard somehow because there's no way to unambiguously encode them in the standard for time_t. So, you can say those things, but I'm not at all optimistic that things will change. Of course, that won't change the fact that they are part of the standard, and something more sensible than throw a 1 second error (or worse) needs to happen. Especially the "or worse" part given the number of bugs related to leap seconds in the past that were more than just a small time keeping error. So I get that computers should implement them right, but until they are "right by default" we'll need skewing to paper over the worst of it. Warner _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs