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.
John Sauter wrote: Dubious value: leap seconds cause UTC, and thus civil time, to track the sun. I don't regard that value as dubious. Warner: 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. John: The idea behind leap seconds is to deal with a long-term problem by making corrections so small that most people don’t care, or at most laugh, when told about them. For almost everyone, leap seconds are inconsequential, and that’s a good thing. The current definition will do for about 1000 years, until the skew between the UTC and UT1 rates gets large enough that we need a leap second before the end of the month to keep abs(UTC – UT1) below 0.9. ===== John: 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. Warner: 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 too 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. John: Perhaps I am, as you say, excessively optimistic. Maybe I am tilting at a windmill, but I would rather light a candle than just scream into the darkness. I am attempting to address the systemic bias against leap seconds in the world by making it easier to handle leap seconds correctly than ignore them. See my “Avoid Using POSIX time_t for Telling Time”. ===== John: 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. Warner: 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. John: We are not slaves to standards—they exist to serve our needs. If we need to keep track of time accurately, and find a way to do so, the standards will catch up. POSIX time_t is fatally flawed when used for the purpose of telling time. The standard is so weasel-worded as to be practically meaningless. I do not advocate changing the definition of time_t but instead that programmers stop using it. The tm data structure is a much better way of recording an instant of time. To encourage application programmers to stop using time_t I have provided a package of subroutines which manipulate the tm structure. My hope is that application programmers will use these subroutines because they are easier to use than manipulating time_t directly, and will thereby handle leap seconds correctly without any extra effort on their part. John Sauter
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
