[LEAPSECS] leap minute or hour

[Zefram]

Eric Scace wrote:
>   This is much easier to deal with than writing code for future leap
>   second changes on dates yet to be established/promulgated.

It does ameliorate the problem of distribution of the leap schedule,
but that benefit is not at all specific to the leap minute/hour system.
The distribution is made easier by having a twenty year lead time on
scheduling, and this feature of the system is not at all dependent on
the nature of the schedule.  We have previously noted that there would be
value in a multi-year lead time in scheduling leap seconds of the current
form (individual leap seconds, making an effort to minimise |UT1-UTC|).

If the intention is for UTC to track UT1 over the long term, even if it
has a much greater tracking bound than previously, then we need to be
prepared to handle leaps.  In this context, there is a major disadvantage
to the leap minute/hour proposals, and even to just embargoing leap
seconds for a century: they would result in needing to handle a leap
when no one has experienced a leap for decades.  What are the chances
of getting that right?  If we're going to have leaps at all, it seems
better to keep leaps reasonably frequent, and even to insert gratuitous
leaps to make them more frequent than at present (see the "leap second
every month" proposal).  This way we would have a fair chance of making
the leap-handling systems actually work.

The CGPM resolution is, of course, taking the opposite approach,
reasoning that leap seconds are just too hard to get right.  This seems
a poor justification for abolishing a mechanism that's good for
some applications, but if taken at face value it's even worse as a
justification for any mechanism that would have very infrequent leaps.
Leap seconds every couple of years are hard, true, but leaps once a
century would be far harder to get right.  As has been previously noted
in respect of the leap hour proposal, the CGPM resolution really looks
like an attempt to abolish leaps entirely (which is what its rationale
really justifies) without actually admitting that that is the aim.
This is especially so with the proposal being so vague about what it
intends to happen to UTC after the leapless century.

The resolution has a note about TAI being insufficiently accessible to
serve the technical purposes that require a completely regular time
scale.  This seems like the thing to work on.  We ought to be making
time distribution systems offer both TAI and UTC, with TAI as the more
fundamental product and UTC explicitly layered on top of it.  That way
the problems of leap seconds can be confined to those applications that
actually want the UT1 tracking.  It's a lot of work, but we actually
need to disseminate two or more time scales anyway, and it's preferable
to do that in a well-specified way.

-zefram