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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
