> The requirement for tables (and, correspondingly, the > "impossibility" of dealing with future UTC dates more than a few > months out) depends on what you're trying to do. You can *talk* > about the dates, and you can do interval arithmetic with a > precision of days, hours, or minutes, perfectly well. The only > thing you need those leap second tables for, I think, is > performing interval arithmetic with a precision of seconds.
Right, which is a common operation, even with dates in the future in the kernel. > In particular, if right now it's 2017-01-05T01:56:13, I can > obviously compute that (say) exactly three years from now is > 2020-01-05T01:56:13, and I can even set a computer alarm to > go off then, even if neither I nor the (suitably programmed) > OS kernel that's tracking the alarm know in advance how many > leap seconds there might end up being between now and then. Except that's not how things are programmed. Programming it that way would be very inefficient in a part of the kernel that has to be ultra-efficient. Since you don't know how many seconds it will from now, you can't schedule a timeout. The current setup of UTC doesn't let me know how many seconds it will be in the future. People can talk about it, but computers don't always store things that way. The non-uniform radix presents problems. Trying to play semantic games like this doesn't change that. There's problem, and trying to equivocate away by saying "well, if you just did it right it would be OK" isn't a helpful position. Requiring every computer to do complicated things so that a leap second can work once in a blue moon isn't a good engineering tradeoff. Ignoring the people that have actually implemented things when they tell you that it's a bad design isn't going to help make the design better.. Warner Warner _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
