[LEAPSECS] Civil timekeeping before 1 January 1972

[Brooks Harris]

Hi Tom,

On 2015-03-12 02:57 AM, Tom Van Baak wrote:
> Brooks,
>
> A couple more comments on your questions.
>
>> Many timekeeping systems seem to be designed for only indicating "now"
>> counting forward, including NTP, POSIX, and PTP, taking short-cuts to
>> avoid supplying full Leap Second and local-time metadata.
> I'm not clear why you call that a "short-cut". It's just how clocks works.
Right, that's how a traditional clock works but that's fundamentally 
inadequate when the UTC counting methods are in use. What I meant by 
"short-cut" is that the UTC metadata (Leap Second announce and table) 
are generally not provided or accounted for. NTP and POSIX drop the 
23:59:60 count. They work like a traditional clock, not like a "UTC clock".
> They tick forward and there is no requirement that they keep a record of time in the past.
Right, Thats' the traditional concept of a clock. But we very much need 
to calculate durations - "how long ago did an event happen?", "how long 
was it between event A and event B?", "when is event A scheduled to occur?"

Traditionally, days were 86400 long, so calculating durations was 
simple. Days are 86400 long in NTP and POSIX, so calculating durations 
is simple BUT it doesn't match UTC! How many seconds between 
1972-06-30T23:59:59Z (UTC) and 1972-01-01T00:00:00Z (UTC)? Two, not one, 
because in NTP and POSIX 1972-06-30T23:59:60Z (UTC) went missing.

> Furthermore, any clock keeping UTC has no need for local time metadata. So you should not lump the tz mess into the simplicity of keeping UTC.

Right, well, typically the objective is to indicate "local civil time". 
Only those jurisdictions at -00:00 offset from the UTC can use UTC, and 
even then might observe Daylight. Humans care about "local civil time" - 
only the timekeepers care about UTC who use it as the reference 
timescale from which "local civil time" is derived. Yes, of course, the 
whole topic of the tz mess is dragged into the calculation, which is 
outside of UTC timekeeping discussion proper, but still required for 
practical purpose of indicating "local civil time" and coordinating 
activities by those time representations.

> The only thing a UTC clock requires is advanced notice of the length of the current minute.
In principle the announce could be even faster than that to keep 
counting forward, but to schedule an event in the future you need either 
the next upcoming Leap Second or how long in the future *we are sure* 
there will not be a Leap Second.

> This is required by no later than second 58 in the minute.
Right.
> But for practical reasons a UTC clock typically gets more notice than that, as you know.

The more notice you have, the further in the future you can confidently 
schedule, or predict.

Currently the announcements are essentially done by humans. ITU-R Rec 
460 says "The IERS should decide upon and announce the introduction of a 
leap-second, such an announcement to be made at least eight weeks in 
advance". That gives the humans at IERS time to create and publish 
Bulletin C and presumably all the timekeeper humans enough time to 
implement the upcoming Leap Second into their time servers or protocols.

IERS has done this "at least eight weeks in advance". The most recent 
Bulletin C was issued nearly six months in advance. Note, however, its 
not clear *exactly when* it was issued. I became aware of it like on Jan 
2, but you'd really like to know *exactly* when it was issued.

Of course you'd really like to have this notification *automatically* 
issued and taken up by all time servers, protocols, and applications 
everywhere.


>> I've never
>> been able to understand why that practice persists despite the obvious
>> need to be able to fully represent the entire post-1972 UTC timescale.
>> The policy and forms of the announce signals and Leap Seconds table are
>> obvious missing links, and its regrettable no official attempt has been
>> made since 1972 to rectify those inadequacies.
> I don't know what you mean by represent the entire post-1972 timescale. Or why such a need is "obvious".
As Warner said in another LEAPSEECS post -

"A clock doesn’t need to know its past. But a time scale is more than 
just how many seconds the current minute will have. It has a history and 
to compute elapsed time in that time scale, you need to know its history."

You don't have a definition of what your clock means if you don't have a 
specification of the timescale its representing. For the UTC timescale 
you need the Leap Second metadata - all of it.

>
> A clock does not need to represent the infinite past, present, and future of a timescale. In the case of UTC the near future is unknowable anyway. The present is the requirement. And the past may or may not be a requirement depending on the user. Certainly a stand-alone RTC or time code generator or data logger or cesium clock keeping UTC does not need to know the past. So a historical table is not important. Only the leap second notification is needed.
>
> That's why the time codes you see broadcast, like WWVB or GPS only include a leap second notification and not a full table.
>
> By the way, the downside of WWVB's format is that it is not possible to obtain TAI. With GPS, at least, TAI is not only possible but easier and more reliable than UTC.

Long ago it was decided to disseminate time as UTC. This to maintain 
continuity with the tradition of representing time as the "solar day", 
or "mean solar day". I think that's the right approach, but the 
specifications are unclear and incomplete, not to mention the "local 
civil time" difficulties, which really overwhelms the TAI/UTC trouble as 
far as accuracy is concerned.

If you have all the metadata (Leap Second announce, expiration, and 
table) its easy to convert between UTC and TAI. With that you can 
calculate accurate elapsed times and schedule as far in the future as 
the upcoming Leap Second and expiration allow.

Conceptually you could think of UTC as really a dissemination of TAI, 
but *encoded* with the "UTC counting method". But the broadcast UTC time 
stamps don't have the metadata to make the conversion, so its incomplete 
by itself, and there's no way to reliably, officially, and automatically 
obtain the metadata.

Meantime there are the widely used NTP and POSIX timescales which are 
obviously flawed in their counting of UTC, but these too can be 
converted to TAI or UTC if the metadata is available.

Imagine BIPM, IERS, and ITU had originally done it the other way round - 
disseminate TAI together with metadata to convert to UTC. Then you could 
represent the timescales. But that's not what happened - they 
distributed a UTC "clock", not the whole timescale.

In my opinion the central problem is the missing UTC Leap Second 
metadata. Of course that by itself doesn't address the "local civil 
time" challenge, but it would at least help eliminate the problems of UTC.

Simply "eliminating Leap Seconds" from the UTC time dissemination values 
might help some faulty implementations from crashing or hanging, but it 
could also evoke new unknown problems and bugs in other implementations. 
By itself it doesn't eliminate the timekeeping difficulties in general. 
It would only muddy the waters and disconnect us from the centuries old 
tradition and goal of timekeeping by the Sun's position. From a 
standard's point of view I think its just too dangerous to change the 
procedures.

I think we're stuck with UTC, and UTU-R should add a forth option to 
their agenda - go about defining a new modern way to distribute the 
official UTC metadata.

-Brooks

>
> /tvb
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>