[time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

Martin Burnicki martin.burnicki at burnicki.net
Mon Jul 25 10:21:08 EDT 2016


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".


More information about the time-nuts mailing list