[LEAPSECS] alternative to smearing

[Warner Losh]

> 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