> >> 3) maximize scheduling horizon.
> >
> >That's one of the issues with leap hours - it's easy to maximize a
> >schedule, simply never do something. I believe this is really a
> >question of imposing a fixed schedule that happens to be of long
> >duration. Perhaps I misunderstood your point.
>
> This is the main objection to leapseconds as they are now: we get
> too short notice.
Right now the notice given for a leap second is necessarily <= 6
months. This is too short a period of time for many embedded devices
that need to know what the leap seconds will be further out than that,
or at least could be made more reliable if they did know the schedule
out longer than that.
One thing I've proposed on other lists is to allow UT1-UTC to get as
large as say 5s or 10s. Then predict the number of leap seconds we'll
have over the next 10, 20, 50 years (whatever the state of the art is
believed to be to keep DUT1 in that new, looser range). We then
schedule today that they will happen at these times over the next 10,
20 or 50 years. The earth's natural variation may mean that UT1-UTC
is > 1s during these times, but is still bounded because we've added
these seconds. If we had a 10 year schedule, every 2 years or so the
next two years would be scheduled. Eg:
Jan 1, 2006 announce leap seconds through 2016.
Jan 1, 2008 announce leap seconds through 2018.
etc. This would still allow for the sychronization of the civilian
time scale, while still allowing for more predictability. Over time,
we could likely expand the time horizon for the predictions (eg do it
out 15 years instead of 10, then 20, then 25, etc).
Such a scheme would optimize multiple variables, with no single one
dominating. Leap seconds wouldn't be eliminated (drat!), but neither
would we try to optimize things so closely to the earth's rotation as
to sacrifice long term planning.
Look what predictability did for leap days...
Warner
