On Fri, Dec 30, 2016 at 9:52 PM, Steve Summit <[email protected]> wrote: > 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.)
Other systems don't have this quite yet, but I'd love to see it more widely implemented. Is there a spec for this yet, or is it just whatever code is noodling around in Linux? > 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.) To do this, one would need to tell the kernel that a new leap second is introduced. That's not too bad, but you'd also need to then run through all the timers in the system to adjust the time that the UTC timer was going to fire to be a new time (by removing and inserting it into the right list). While there are a number of different clocks that can be reported, timeouts are still in the absolute ticking monotonic thing. Doing a time conversion on every timeout is likely to be too expensive since they get called a lot and tend to be the critical path. But I'm curious how you'd represent a leap second in this scheme? I'd like to schedule a timeout in the UTC time during the leap second (because it's the next second, or in 5 minutes or whatever, not because there's something special about it, but because there shouldn't be something special about it). How is that encoded into time_t? Its easy to encode in TAI time, but not so easy to encode in UTC time. It's especially troublesome if the kernel decides that there really isn't going to be a leap second at midnight for some reason (like a bad ntp server leaked the wrong data which was later corrected). It might be easiest if there's a flag on the UTC timeouts that could be adjusted across such events... Not ideal, but not horrible. Warner _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
