[LEAPSECS] alternative to smearing

[Hal Murray]

>> 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.
> IMHO, that's yet another example of the "it's only a second" attitude that
> keeps us from having nice things like a working UTC implementation on Unix.

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 was assuming that the API to the kernel was wait N seconds.

If you want to schedule something for a month or year from now, I was 
assuming that there would be a library routine that took a Y/M/D-H/M/S type 
format and figured out how many seconds to wait.

Somebody else mentioned performance critical.  I was trying to ask if there 
was anything performance critical about the library code that was translating 
from a calender style date-time to seconds-to-wait.

I hate bloat and crufty code as much as anybody.  A library routine to handle 
all the quirks of leap seconds and leap years and daylight savings seems 
reasonable to me.  But maybe I'm overlooking somethings, so that's why I 
asked.



-- 
These are my opinions.  I hate spam.