On Tue, Apr 18, 2017 at 6:20 PM, Nico Williams
<nico(_at_)cryptonector(_dot_)com>
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.