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 _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
