[LEAPSECS] alternative to smearing

[Steve Summit]

Hal Murray wrote:
>>> Are there any performance critical chunks of code that want to wait until N
>>> years from now?  I doubt it.
>
>> With due respect, that's a crappy attitude to getting something right. You
>> want to have one interface that always works that's easy to use and schedule
>> with. If you don't have that, then your software is more likely to break.
>
> I think there are two different types of wait.  One is the simple wait N 
> seconds.  The other is wait until a specified date-time, say a month from 
> now.  They really are different so I don't see how to make your "one 
> interface" work.

I think there are several issues here that people are coming at
from different directions.

In a leapsecond-aware world, I believe there are two kinds of
wait, "relative" and "absolute".

In a no-leapsecond world, absolute waits can be converted into
relative ones so trivially (or vice versa) that there's hardly
any difference between them.

But in a leapsecond-aware world, yes, you have to treat them
separately, so it's reasonable to object that the higher code
complexity is a cost.  Also the absolute timer may have to
"wake up" periodically and recompute itself in case anything has
changed -- a new leap second has been announced, for example --
so it might also be reasonable to object that the inefficiency is
a cost.

When Hal had asked earlier, "Are there any performance critical
chunks of code that want to wait until N years from now?", I read
that as wondering whether it really mattered if the handling of
that presumably rare case might be less efficient, not as
suggesting that handling the case correctly might not be
important at all.

Turning back to code complexity, if you want your time and timer
code nice and simple, with no duplicated or redundant code, I
guess you better not use Linux!  The code is crazy complicated,
and there have been two separate sets of timer code, regular
and high-resolution, with an apology in the documentation
(hrtimers.txt) that it wasn't possible to unify them.  So, while
proper leap-second handling will, I concede, further increase the
complexity in some areas, it will not tip the balance from "nice
and simple" to "painfully complex"; that camel's back was broken
a long time ago.