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