[LEAPSECS] alternative to smearing

[Steve Summit]

Warner Losh wrote:
> Steve Summit <scs+ls at eskimo.com> wrote:
> > 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...
> > 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... 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.

Indeed.  Did you see the message a few hours ago where I
mentioned the "New Jersey approach" (aka "Worse is better")?

But my point, my quibble with tvb's list, was that he said that
some things were impossible or require leap second tables, when
in fact they're merely difficult (to the point, depending on your
engineering tradeoffs, of being a bad idea) or sometimes require
leap second tables.

I don't think that saying something is impossible, when it's
merely difficult, is helpful either.