[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. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
