[LEAPSECS] alternative to smearing

[Hal Murray]

[do something N years in the future]
> 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. ...

Are there any performance critical chunks of code that want to wait until N 
years from now?  I doubt it.

If I ask for 6 months rather than a few years, then you also have to consider 
daylight savings.  Actually, you have to consider it anyway.  Congress might 
change the start/stop times again and your wait-until might hit one of them.

I think that means that if you want to schedule something a long time in the 
future specified as date and time rather than seconds from now, you have to 
wakeup a bit early and recompute how long to wait.  For leap seconds, the bit 
early has to be a few months, depending on how long it takes you to update 
your leap file.  For daylight savings, I don't think you can predict a value 
of a bit early.  Congress isn't dependable.

How far in advance were the last daylight savings changes announced?


-- 
These are my opinions.  I hate spam.