[LEAPSECS] multiple UTCs

Zefram zefram at fysh.org
Wed Jan 18 09:24:32 EST 2012


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


More information about the LEAPSECS mailing list