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. _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs