> On Dec 14, 2015, at 9:18 AM, Ian Batten via LEAPSECS > <leapsecs@leapsecond.com> wrote: > > I was talking about this to a colleague, and they pointed out an obvious > point that perhaps those of us who follow these things might miss. > > Between now and 2023 there will be at least two leap seconds, to a high > degree of probability. With there now being a lot of focus on leap seconds > and their effect on computer systems, on the first such leap society as a > whole will be able to gauge the scale of the problem. And as there is > certainty of at least one further leap, people affected by those problems > (which personally I hold to be wildly over-stated, but I am willing to be > convinced) will have every reason to fix them. So come 2023, the discussion > will be largely about problems which arose and were fixed, because anyone who > says “we have this problem which we have decided not to fix” is admitting > that either the problem is not serious or they are not sufficiently bothered > by it to fix it.
You’ve left out one bit. Problems too systemic to fix. POSIX time_t likely isn’t going to change between now and then. It isn’t that it isn’t important enough to fix, but rather the impact of the “fix” would be too costly and systemic to endure. That’s very different than not serious enough to warrant fixing. There are a number of things that can be done to mitigate the bad standard. These will be sufficient for some people, and not sufficient to others. The may even be irrelevant to others (Linux kernel bugs in this area are because they are doing leap second processing, at all, so anything that doesn’t eliminate them won’t eliminate the risk). UTC skewing over leap second is one example. This solution works great for many people (Hi Goggle), but less great for others (wall street’s most recent requirements were for significantly sub-second accuracy for trade timestamps). There’s also associated cost with there being leap seconds at all, even if there are absolutely no problems found. Since it is an exceptional event, there’s cost in code size to handle the exception. There’s cost in CPU for the additional code, there’s additional cost to write, run and maintain the tests. There’s opportunity costs for all this effort. There are programmer training issues. There are issues with budgets needing to increase to support these activities in the middle of a fiscal year due to the current announcing schedule. It could likely be that by 2023 these will be well documented enough to show that, although the problems may be adequately being addressed, the cost of the leap second is more than can be cost justified. Even if you try to wave away these problems today, it doesn’t necessarily follow they won’t be problems tomorrow. The time scales inside the computer are shrinking, more computers are more connected to increasingly precise systems where 1s jumps are bigger problems than they were in the past. It’s hard to gage where we’ll wind up in 8 years. So there’s many problems with the assumption that if something isn’t fixed by then, it isn’t an important problem. > So in 2023, there will not be a list of open, unfixed issues to motivate > change, because everything will either be fixed or deemed trivial (fsvo > trivial). This is not true. Since your assumption was invalid, this conclusion is also invalid. > But there will still an unbounded, uncollected list of unaddressed issues > surrounding cessation of leapseconds. That’s because it’s entirely > reasonable in 2015 to develop systems assuming |ut1-utc|<0.9, and no reason > at all to alter systems with that assumption. It hasn’t been safe to assume DUT1 < 0.9 in perpetuity for some time (not for the decade that talk of eliminating leap seconds has been going on). I don’t see how this changes that assumption. There’s nothing magical about a 1s tolerance, other than it has been the spec for a while. With increasing data flow and increased connectivity, systems can more easily be designed in the future where such assumptions aren’t needed. Given all the discussion about leap seconds, and the deployment horizons beyond 2023, I can’t see how one can say that it would be safe to assume what the resolution will be at that time. Prudence would dictate reducing assumptions to avoid future change. Warner > ian > >> On 19 Nov 2015, at 15:58, Kevin Birth <kevin.bi...@qc.cuny.edu> wrote: >> >> Predictable. >> >> >> >> On 11/19/15, 9:49 AM, "LEAPSECS on behalf of Steve Allen" >> <leapsecs-boun...@leapsecond.com on behalf of s...@ucolick.org> wrote: >> >>> The news is official. Leaps until 2023, and more studies. >>> >>> https://www.itu.int/net/pressoffice/press_releases/2015/53.aspx >>> >>> -- >>> Steve Allen <s...@ucolick.org> WGS-84 (GPS) >>> UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 >>> 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 >>> Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m >>> _______________________________________________ >>> LEAPSECS mailing list >>> LEAPSECS@leapsecond.com >>> https://pairlist6.pair.net/mailman/listinfo/leapsecs >> >> _______________________________________________ >> LEAPSECS mailing list >> LEAPSECS@leapsecond.com >> https://pairlist6.pair.net/mailman/listinfo/leapsecs > > _______________________________________________ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > https://pairlist6.pair.net/mailman/listinfo/leapsecs
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
