Warner Losh wrote: > On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray <[email protected]> wrote: > >> One could imagine having a more complicated structure that could cope with > >> the inherent ambiguity in future times. I can't say "schedule an event > >> exactly 1 year from now" for example without it. I need additional metadata > >> around to know if I want it to happen at the same time of day on the same > >> date or if I want it to happen after than many seconds have elapsed. > > > > Could that be solved with 2 functions in the API, one for N seconds from > > now, > > and a second for at some future date/time specified in Y/M/D/H/M/S format > > rather than something like a time_t? > > Only partially (meaning only assuming every day has exactly 86400 > seconds). These operations are possible today, since the former is += > and the latter is timegm(), sorta, but neither groks leap seconds.
I think we can do better than that, even today. If you want to do something in N seconds, schedule a conventional alarm. (And, yes, using today's code, you'll always get N seconds that ignore leap seconds.) But if you want to do something at a particular future time, and you don't care (or can't predict) exactly how long from now that'll be, you can do that today, too, with clock_nanosleep and the TIMER_ABSTIME flag. In principle, it's straightforward to define meaningful behavior for both relative and absolute timers which run on Posix, TAI, or true-UTC timescales -- that is, with clockid tags of CLOCK_REALTIME, CLOCK_TAI, or CLOCK_UTC. Implementation of some of the combinations is likely to be difficult, but hopefully not impossible. (CLOCK_TAI is already in the newest Linux kernels, but I'm not sure how well it works; CLOCK_UTC is, shall we say, emerging.) One key point is that while scheduling a future event to occur at an absolute time does indeed necessarily require naming that time, this does not -- repeat not! -- become impossible just because we can't know how many leap seconds might occur between now and then. If the true-UTC representation is properly designed (that is, if it is *not* realized as, say, a monotonic, leapsecond-observing count of seconds since the epoch), you can construct a future true-UTC timestamp, using a new mktime variant, just as easily and accurately as you can construct a future time_t value. (In other words, we should not have to assume 86400-second days to do these things.) _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
