4 ms·
Honestly, I think that leap seconds were simply a mistake. We could have phase-locked UTC to UT1R via frequency changes instead of via phase changes and much o
by brandmeyer 8y ago
Honestly, I think that leap seconds were simply a mistake. We could have phase-locked UTC to UT1R via frequency changes instead of via phase changes and much of that hassle would have been avoided.
UT1R is a time of day measurement that is based on making astronomical observations to establish the Earth's angular velocity and phase very precisely with respect to TAI. Leap seconds are created from time to time to keep the offset between UTC and UT1R to less than a half-second.
In effect, UTC is slaved to UT1R via a PLL that is only capable of making phase jumps. Instead, we could have slaved UTC to UT1R via a PLL that only ever made frequency changes. There would be no phase jumps (leap seconds), just very subtle adjustments in clock frequency. Those adjustments are fine enough that the majority of users don't care. The remaining users were already using TAI anyway.
- kazinator 8y agoLeap seconds are nothing to worry about when you're dealing with calendar times and dates in business. They are just a real-time clock adjustment which disappears from the calendar, which uses calendar seconds. We can't phase lock real seconds to calendar seconds, because calendar seconds are a moving target. As the Earth's rotation slows, calendar seconds get longer. Seconds that get longer are not acceptable in science.
- brandmeyer 8y ago> We can't phase lock real seconds to calendar seconds, because calendar seconds are a moving target. As the Earth's rotation slows, calendar seconds get longer. Seconds that get longer are not acceptable in science. Sure you can, and yes they are. There can be a difference between calendar seconds and atomic seconds. For most applications the difference is irrelevant. People doing science can explicitly account for the differences. And since most time-keeping in science is much more inaccurate than the difference between the speeds of TAI and UT1R, those folks won't care. Most of the applications that do require very precise timekeeping actually only care about having a very consistent timebase, they don't necessarily care as much about the speed of time. So even if we steered GPS time by enough to use it as a broadcast source of UT1R, the majority of users who use GNSS to synchronize their measurements also don't care. The remaining handful that do care are going to be purchasing atomic clocks anyway, and there are dedicated mechanisms available to synchronize those to TAI.