[LEAPSECS] New terminology will be needed.

[Dennis Ferguson]

On 6 Jan, 2012, at 01:56 , Steve Allen wrote:


> On Thu 2012-01-05T17:40:09 +0000, Zefram hath writ:

>> I think the point is to have a term for TAI - 35 s, or whatever the

>> formula ends up being.  We'll need to distinguish between these time

>> scales at least:

> 

> but wait, there's more

> 

> The ATSC-Mobile DTV Standard defines the AT epoch as

> 1980-01-06T00:00:00 UTC, refers to it as the GPS epoch, and uses the

> language GPS seconds and GPS time.

> http://www.atsc.org/cms/standards/a153/a_153-Part-2-2009.pdf

> 

> And the IEEE 1588 (PTP) uses TAI seconds from an epoch two seconds

> offset from 1970-01-01 UTC such that PTP time is what is expected as

> the value of POSIX time_t for a system which wants to use the "right"

> zoneinfo files.


There is worse than that.  If you can parse the rather painful description
in Section 4.2 here

    http://www.pttimeeting.org/archivemeetings/2007papers/paper1.pdf

you may (or may not) be able to conclude that the time when the Galileo
System Time started counting from zero (which is what I would call the
"epoch" for the timescale) is 1999-08-21 23:59:47 UTC.  Beidou's epoch
is 2006-01-01 00:00:00 UTC; it was 2000 before, but they advanced it past
the next leap second for some reason.



> No matter what the ITU-R does later this month there are going to be

> numerous parallel time scales in use.  It's just a question of how

> many, and how their specification documents will next be rewritten

> in order to clarify what means what.


It is worth noting that this plethora of time scales is precisely
the concern of the ITU-R.  There is a nice quote from Louis Essen
in the early 1960's (which I wrote down when I saw it presented,
but promptly lost) to the effect that time scale chaos will ensue
if we don't pick exactly one timescale that everyone agrees to
maintain and disseminate, with all other "technical" timescales being
maintained by their relationship to that one.  UTC was supposed to
be the dissemination timescale, but the very fact that pretty much
every new precision time distribution service which has come into use in
the past two decades has explicitly avoided distributing UTC as their
system time in favor of inventing their own timescale (save GLONASS,
which did use UTC for their system time and suffered for it early on
until they got enough practice at handling the leap seconds), is exactly
what wasn't supposed to happen.  To the ITU-R, then, UTC doesn't work
for the (sole) purpose the ITU standardized it for, which was to avoid
having a menagerie of timescales being distributed, all slightly
different.

This really is a fundamental system design problem having observable
consequences right now, like Android smartphones whose clocks are
(to sub-millisecond precision) 15 seconds fast.  To fix it they need to
find a timescale that everyone will agree to distribute to replace the
one that no one will distribute except as a sideline to the main event,
if at all.

Clearly this won't get fixed later this month, but it might after
(and if) the leap seconds actually stop.  Each system's times are
interpreted in terms of an arbitrary, well-known epoch in any case, so
when the leap seconds stop those services will probably retroactively
acquire a new well-known epoch measured in terms of a proleptic, leap-less
UTC timescale (which, I guess, is the same kind of epoch NTP and standard
POSIX have been using all along, so we know that works for some value of
"work"). Old receivers will still use the old epoch and wait for the UTC
offset to arrive, but new receivers will go ahead and compute UTC directly
from the system time and the new epoch, ignoring the UTC offset altogether.
Voila, we're down to one distributed timescale.

Dennis Ferguson