Bob, Bob Camp wrote: > Hi > > The practical problem with any change to leap seconds is transition from what > we have > to the “new system”. Anything other than dropping them altogether involves a > *lot* of > coordination. You pretty much have to pick a date and bring everything onto > the new > standard then. For testing purposes your time sources should “advertise” the > new > information ahead of that date. As a practical point, that means a new field > in the data. > In the case of GPS and other space based systems, that’s not going to happen.
But if you - stick with the leap seconds with UTC as-is - let the kernel alternatively run on TAI instead of UTC - keep existing API calls as they are, returning UTC - introduce new API calls which tell if the kernel runs UTC or TAI and let you query the TAI time stamps then both kernels and applications could make a change over to the new timekeeping seamlessly. I agree this wouldn't fix all problems you may have with leap seconds, but it would at least avoid problems like "the kernel hangs when the system time is stepped back by 1 s to account for a leap second". Martin _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
