Warner Losh wrote: >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,
https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html >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 You're prejudging the implementation too much. The kernel does need to know about each leap second by the time it happens, but it does not need to convert timer expirations between TAI and UTC immediately when the timer is set. Nor does avoiding this imply performing conversion in the hot path on timeout. It suffices that timer settings get converted to the operational time scale *sometime* between when they are set and when they expire. If a timer is set to expire a year hence, it would not be difficult to postpone the conversion until a few minutes before it expires, by which time one can expect to be able to perform the conversion correctly. >But I'm curious how you'd represent a leap second in this scheme? CLOCK_UTC is defined to use 1e9 <= tv_nsec < 2e9 in struct timespec, by implication with tv_sec the same as it is for the preceding second. > It's especially troublesome if the kernel decides that there >really isn't going to be a leap second at midnight for some reason That would require a decision on what it means to have set a timer for a time that doesn't actually exist. It's not difficult to implement any of the reasonable options. > It might be easiest if there's a flag on the UTC timeouts >that could be adjusted across such events Handily, clock_nanosleep() already has a flags parameter that could be used for that purpose. -zefram _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs