On Tue, Apr 18, 2017 at 6:20 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
On Tue, Jan 03, 2017 at 05:34:11PM -0500, Phillip Hallam-Baker wrote:
> As I said, I want 30-100 years lead time so I can bake the schedule into
> devices and remove a trust dependency.
30 years' lead time for leap seconds? Can't be done.
Leap seconds depend on events such as earthquakes.
You can estimate their frequency, but you can't estimate when they'll be
inserted.
Of course it can be done. I can show you one very simple algorithm that allows every leap second to the end of time to be known right now:
"All leap seconds are abolished. UTC = TAI +37 for all future dates."
We do not need to let the astronomers mess around with time according to their calendars. What I proposed was to define PIT in such a way that the difference between PIT and UTC is highly unlikely to be more than 5 seconds but the table of leap seconds is set 30 years ahead of time.
The basic scheme is to observe the current frequency of leap seconds (8 in the past 30 years) and use a simple linear extrapolation to approximate that for the next 30 years. For dates after 2047, the leap second table and approximation function will be updated so as to minimize the divergence between PIT and UTC. If UTC is ahead of PIT in 2018, then an additional leap second will be scheduled for 30 years in the future, unless a leap second would have been scheduled for that date anyway in which it will carry over to the next year.
The scheme proposed guarantees complete predictability over a 30 year timespan while ensuring that the deviation between PIT and solar time is never more than a few seconds. If the frequency of leap seconds becomes too high, the extrapolation function can be changed. At the end of the day, the earth is only going to speed up its rotation for very brief intervals, the long term trend is always downwards.