On Thu, 2016-07-21 at 10:27 -0700, Tom Van Baak wrote: > Time to mention this again... > > If we adopted the LSEM (Leap Second Every Month) model then none of > this would be a problem. The idea is not to decide *if* there will be > leap second, but to force every month to have a leap second. The IERS > decision is then what the *sign* of the leap second should be this > month. > > Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with > UTC, not so much by rare steps but by dithering. There would be no > change to UTC or timing infrastructure because the definition of UTC > already allows for positive or negative leap seconds in any given > month. > > Every UTC-aware device would 1) know how to reliably insert or delete > a leap second, because bugs would be found by developers within a > month or two, not by end-users years or decades in the future, and 2) > every UTC-aware device would have an often tested direct or indirect > path to IERS to know what the sign of the leap second will be for the > current month. > > The leap second would then become a normal part of UTC, a regular > monthly event, instead of a rare, newsworthy exception. None of the > weird bugs we continue to see year after year in leap second handling > by NTP and OS's and GPS receiver firmware would occur. > > Historical leap second tables would consist of little more than 12 > bits per year. > > Moreover, in the next decade or two or three, if we slide into an era > where average earth rotation slows from 86400.1 to 86400.0 to 86399.9 > seconds a day, there will be zero impact if LSEM is already in place. > > /tvb
I suggest a less intrusive procedure which would have some of the same benefits. Every serious project includes a test procedure to verify that the product is working. That test procedure involves running the product within a test harness which feeds it inputs and records its outputs. Within that test harness, pretend that every minute ends with either a positive or negative leap second. Bugs in the handling of leap seconds will thus be found very quickly. This procedure can be implemented by a product developer without getting co-operation from the IERS or any other external entity. However, it does not address the problem of timely access to the IERS. John Sauter ([email protected]) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
