On Fri, Nov 18, 2022 at 9:34 PM Zefram via LEAPSECS <leapsecs@leapsecond.com> wrote:
> 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. > Alternatively, why does | UTC - UT1 | need to be bounded? If we let it accumulate to an arbitrary level, and distributed UTC - UT1 to anybody that needed it, then that would accomplish the same thing that adding leap seconds does now, without the approximation that UTC ~ UT1. All applications that care updated to use this value could even have a higher level of performance without the need to hope that the UTC approximation is 'good enough'. This completely eliminates leap seconds from timekeeping while putting the onus on the applications that care to pay the freight while removing the leap second tax from the 99.99% of applications that don't care. Warner
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
