[LEAPSECS] presentations from AAS Future of Time sessions

[Warner Losh]

On Jan 9, 2014, at 10:15 PM, Magnus Danielson wrote:


> On 06/01/14 19:40, Rob Seaman wrote:

>> PDFs of the slides from the talks yesterday (5 Jan 2014) are now available at:

>> 

>> 	http://www.cacr.caltech.edu/futureofutc/aas223/

> 

> Thanks for the pointer.

> 

> Reviewing Kara Warburton's presentation I have one comment.

> The concept of a international time-scale with no leap-second isn't a new concept. It already exists even if it's use have been discouraged. It's called TAI. TAI, or shifted versions of TAI such as the GPS time-scale, is already being used when a no-leapsecond base is needed.

> 

> When UTC needs to be realized, providing a side-channel holding leap-second could and when new leapseconds is going to be introduced is being built, and is well understood how it needs to work from the existing standard, and it works.

> 

> Using TAI instead of UTC in the POSIX time_t engine works out of the box, but causes greif when UTC is required, as POSIX has no defined side-channel for handling the TAI-UTC difference. Adding such a side-channel interface to be optionally included for those needing the actual UTC and used by applications where using actual UTC is needed will be the fix to POSIX that is a result of not including leap-seconds properly into time_t. The side-channel is needed even if retaining the current UTC to time_t mapping.


A TAI realization of time_t isn't POSIX, which specifically proscribes UTC. It also specifically states that all times that are 0 modulo 86400 must be midnight so that "simple math" will work converting back and forth between broken down time and counted seconds. However, it proscribes UTC without a way to represent a leap second. That's a far more fundamental problem with POSIX than the side channel.

The side channel issue is why I've advocated, with others, a much longer time horizon for leap seconds. This would allow the useful life of most products to have no need for a communications side channel to get this data.

But the side channel isn't strictly necessary. You can realize UTC without leap seconds with POSIX time_t if your time error tolerance is great enough and you have some other synchronization method.  However, it is necessary if your time error tolerance is tighter than that.

Various people can, and have, run with the 'right' timezone where they break the 'simple math' rules in a few ways to get leap seconds included. But there are logistical problems with long running programs doing that (since there's no provision to reload the leapsecond tables if your daemon has been running for 6 months and a new leap second that was unknown when you started needs to happen).

While you boil all this down into "side channel" no doubt, the lack of its existence is a fatal flaw in time_t, as its complete inability to encode leap seconds. Trying to make it out to be something so simple trivializes, bogusly, the operational problems leap seconds can and do cause. It also contributes to the "close enough" mentality that surrounds the leap second where if people get it wrong, who cares, it is close enough.


> Creating a new leap-second free time-scale would just add to the proliferation of TAI variants, and the proposed name is trying to be a TAI variant. It would be more straightforward to accept that there needs to be two international time concepts, with and without leap-seconds. Those concept exists in UTC and TAI respectively. Let's use them that way.


The problem isn't that people want a time scale without leap seconds, per se. The problem is that the way computers realize UTC is so flawed and error-prone that people believe that the whole leap second concept is more trouble than it is worth and to do the science that needs to be done with UTC + DUT1 could easily be done with TAI + DUT1 and everybody just uses TAI. To avoid a large jump UTC's labeling of the seconds would become TAI's. Sure it is one more time scale, but that's not a bad thing as you make it out to be. GPS time didn't destroy the world. LORAN time before it hadn't destroyed the world. etc.