[LEAPSECS] Crunching Bulletin B numbers (POSIX time)

Warner Losh imp at bsdimp.com
Tue Feb 22 16:40:53 EST 2011

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.


More information about the LEAPSECS mailing list