[LEAPSECS] Crunching Bulletin B numbers (POSIX time)

[Warner Losh]

On 02/19/2011 16:25, Ian Batten wrote:

>>

>> to do this correctly for ten years, it would need a ten year leap

>> second table.

>

> Or someone to supply a manual update every two or three years.  If the 

> machine is so isolated that it cannot receive those updates, why does 

> the high-precision timestamp in the logs matter?  This is what I fail 

> to see: systems which are so isolated from timekeeping hat they cannot 

> receive one-bit updates, and yet are so tied into timekeeping that 

> they need to generate and store timestamps to high precision.  What's 

> the use case?  Not some hypothetical, but a real application?


The use case that I have is spares.  Consider systems that are out in 
the middle of nowhere, like a loran station.  This station gets it times 
from GPS and broadcasts the ticks to make sure that things are on time.  
Each station has a spare for all the hardware in the place, powered off 
on the shelf or in a cabinet.  The system needs to be up as much as 
possible, and also has time reporting requirements in UTC.  So, if you 
have a table of leap seconds for the next 10 years, you don't have to 
update the GPS receivers every 6 months, which would require sending 
personel out to these remote locations (the normal operators can swap 
parts out, but can't do upgrades: they lack the skill).  You'd be able 
to get the station back online 20 minutes faster in the event of a GPS 
receiver failure.

The other scenario is when you aren't allowed to update the base system 
except in very special circumstances.  This includes innocuous updates 
to things like the zone files.  Once the system has been qualified, you 
are allowed to deploy it.  Once the system is deployed, it must behave 
exactly the same as all other systems out there, even ones that are 
spares and sit on the shelf for years.  Having a 10-year horizon would 
ensure that you'd be able to deploy these systems and update them less 
frequently than every 18 my nths, which can have some substantial 
cost-savings in recertification time...

Then there's the lazy updater.  People don't update their systems unless 
they have to.  Having a 10-year horizon allows these people to be lazy 
and have their systems "fail safe" instead of "failing wrong and 
hopefully recovering" for a much longer time horizon.

Warner