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@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
