We've talked a bit about tradeoffs between tracking precision and scheduling lead time in UTC. Obviously, any loosening of the tracking precision in order to give more lead time would require changes to those applications that relied on the tighter tracking. So maybe we ought to (a) be explicit about tracking requirements and (b) choose multiple points on the tradeoff spectrum. We could have several versions of UTC, each tracking UT1 using leap seconds, but scheduling leaps with different lead times.
Suppose we have UTC0 which aims to track UT1 within 1 s and schedules leaps a year in advance, which is nearly the current UTC. Then UTC1 aims to track UT1 within 10 s, and schedules leaps a decade in advance. UTC2 aims to track UT1 within 100 s, and schedules leaps a century in advance. And so on, for those with really long planning horizons. Users of UTC should switch to whichever version of UTC meets their needs. A specific choice of UTC<n> implicitly documents the actual tracking and stability requirements of a system, where currently these are often hidden due to not having such options available. Would that be a good system? It's got a really obvious drawback, that it would be liable to confuse. UTC0, UTC1, and UTC2 would all generally differ from each other, but only by a few seconds, and with no secular growth of the difference, so they'd be mixed up by anyone who wasn't careful about it. But hypothetically, if we could avoid that kind of mistake, would such a family of time scales actually be useful infrastructure? -zefram _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs