[LEAPSECS] Crunching Bulletin B numbers (POSIX time)

[Warner Losh]

On 02/19/2011 15:13, Tim Shepard wrote:

>

>> this is why leap seconds announced ten years in advanced

>> are important: they allow for a stand-alone machine, albeit

>> one that only needs to have it's software upgraded once in

>> ten years.

>

> A stand alone machine is going to have its clock drift by more than a

> few seconds over 10 years.    Leap seconds are in the noise compared

> to errors due to accumulated drift of standalone machines.

>

> If it has a way of receiving a time signal to stay synchronized, then

> it ought to have a way of receiving info about the leap seconds (if

> they even matter).


Having a known list of leap seconds let one recover TAI time from a cold 
GPS receiver in a few seconds to a minute, rather than waiting ~20 
minutes for the almanac to download.  Many systems have their internal 
clocks in TAI, but also have requirements to report time in UTC to 
users.  Such a table would ensure these systems could come back online 
quickly without having to pay the 20 minute penalty.  While the system 
may have already been down a little while when the swap is made, an 
extra 20 minutes can kill reliability targets for the system.

As someone that's had to have their real-time system in a time-scale 
that doesn't have leap seconds, but also report timestamped events in 
UTC to the user, the 10-year horizon solves many problems with leap seconds.

As to Posix, I think the standalone system is in the noise compared to 
the amount of code that actively depends on leap seconds not existing.  
It might make a good talking point, but if you eliminate that 
requirement, you still have the dusty deck problem to cope with.

Warner