[LEAPSECS] Time math libraries, UTC to TAI

[Zefram]

Brooks Harris wrote:
>accurate representation before this instant is explicitly out of scope.

In that case, you should have no need to perform any conversions
between time scales for times before 1972.  Yet you insist on particular
(incorrect) correspondences between time scales for such times.  Where you
don't need a representation to be correct, you don't need a representation
at all.

>However, because the NTP, TAI, and POSIX origins lie before UTC1972 we must
>define how these are to be normalized to UTC1972.

No, there is no need to establish any relationship between these origins
per se and the modern horological era.  What is needed is to understand
those systems' representations of *current* times.  For example, with
NTP it is more than sufficient to observe that the UTC1972 epoch is
represented by NTP scalar value 2272060800.  There is no need to consider
any lower NTP scalar value; all NTP scalar values that we actually
encounter may be understood in terms of their offset from that reference.
Indeed, NTP's nominal epoch was deliberately chosen to lie well before any
time we would actually care to consider, to save us the bother of ever
seeing a negative scalar value.  Given that, we should not be surprised
to find that very low positive scalar values are not convenient to work
with, and it would be foolish to insist on somehow making it convenient.

>UTC, with an integral second offset to TAI, *did* spring into existence at a
>single instant; 1972-01-01T00:00:00Z (UTC).

Modern UTC did, yes, but UTC as a whole is older, and you seem to have
a preconception that TAI and everything else also sprang into existence
at the same moment.

>beginning of the modern timekeeping era, the "mother of all epochs".

You grant it an excessive significance.  No time scale is actually
defined by its relationship to that epoch.  It marks the beginning of
the era over which UTC-with-leap-seconds is defined, but that's really
the *only* significance of this epoch.

With respect to defining time scales, there's a much more significant
epoch a few years later, at 1977-01-01 00:00:00 TAI.  This was the
instant at which TAI started to include corrections for gravitational
time dilation.  Its greater significance is that, per IAU resolutions of
1991, TCB, TCG, and TT are all *defined* to read 1977-01-01 00:00:32.184
exactly at that instant at the geocentre.  Those three time scales,
all of which are theoretical ideals, are rare cases of actually counting
SI seconds relative to a defined physical instant, and that instant is
1977 TAI.  If any instant deserves the description of "internationally
agreed reference point" then it is this, not 1972 UTC.

But most of the time representations with which we are concerned do not
count actual SI seconds.  Rather, they are defined in terms of the TAI
or UTC time scales as a whole.  For PTP, for example, there is a defined
relationship between PTP scalar values and TAI timestamps.  PTP doesn't
count SI seconds, it counts the TAI seconds that imperfectly realise the
SI second on the rotating geoid.  The PTP scalar value can be described
in terms of a count of TAI seconds relative to some instant defined by a
TAI representation, but *any* TAI timestamp will serve for this purpose.
The PTP scalar value can be defined as 1262304000 plus the number of
TAI seconds since 2010-01-01 00:00:00 TAI, for example.

NTP is even further removed from actual SI seconds.  An NTP scalar value
is not even a count of TAI or UTC seconds.  It's really a count of UTC
*days*, scaled to count 86400 per day, and bundled with a count of the
seconds within the present day.  As such, any UTC day serves equally
well as a defining reference point.

>               As of that moment the historical non-integer atomic
>time-to-solar time values were rendered obsolete. What justification is there
>to cling to those historical values for practical timekeeping purposes?

Any record from the 1961 to 1971 era that refers to "UTC" must be
understood in terms of rubber-seconds UTC.  It's essential to retain
knowledge of rubber UTC for any purpose involving such historical data.

With respect to generating new material referring to precise instants in
that era, rubber-seconds UTC remains a well-defined way to do so.  It also
retains its original advantages of being both precisely linked to atomic
time and a close approximation of UT1.  If I wanted, now, to describe a
precise time in that era, then rubber UTC would for these reasons be one
of the main candidate mechanisms to do so.  Depending on the application
I might prefer to use TAI, or even a proleptic extension of leap-seconds
UTC, but the lack of widespread adoption of any specific proleptic leap
second schedule would be a significant disadvantage in the latter.

However, my practical timekeeping purposes mostly do not require dealing
with any time prior to around 1990.  In particular, managing clocks and
clock displays doesn't require thinking about any instant more than a
few months old.  In these contexts, no representation of pre-1972 time
is required at all, and so rubber UTC is irrelevant.

>Indeed, that's the rub. It can't be represented in the PTP protocol

That's irrelevant.  There's no call to represent pre-1972 time in the
PTP protocol, by virtue of the purpose of the protocol.

>not computationally very convenient.

Also irrelevant.  PTP operations do not call for you to compute with
pre-1972 time.

>                                     Also, by the reckoning in RFC 5905, NTP,
>RFC 5905 Figure 4: Interesting Historic NTP Dates, NTP Seconds would be
>2,208,988,790. See below.

No, that's you misinterpretating the table again.  We've discussed this
before.  Because NTP scalar values primarily count UTC days, not seconds,
that table doesn't tell you anything about leap seconds.

>In the media business it causes precision implementation problems.

Rubber UTC can't cause you a problem, because you're not recording media
in the pre-1972 era.  You don't need to pretend that rubber UTC didn't
happen; you don't need to take any position at all on pre-1972 UTC.
If your implementation somehow does care about rubber UTC, then you do
have a problem, but the problem is caused by a dumb implementor, not by
horological history.

>The "First day UTC" entry shows an integral number of seconds from "First day
>NTP" to "First day UTC"; 2,272,060,800 s.

No, it shows an integral difference of scalar values.  NTP scalar values
are not counts of seconds.  They are scaled counts of days, and by
inverting the scaling we see that, beyond just an integral difference of
scalar values, the table shows integral numbers of *days* between these
reference points.  It doesn't say anything about the lengths of those
days, which is just as well, because most of those days don't actually
have a defined length in UTC.

>2272060800 / 86400 = 26297 exactly. That's 26297 86400-second-days.

No, that's 26297 days of unspecified length.  Just like the
(3155587200-2272060800)/86400 = 10266 exactly days from "First day UTC"
to "Last day 20th Century".  Those days *do* have defined lengths in UTC,
not all of them of 86400 seconds.

>Note too the "First day UNIX" entry in Table 4. It is also an integral second
>offset from "First day NTP".

No, that too is an integral *days* offset, not specifying the lengths
of the days.

>and I think calling it "TAI seconds" would be confusing because it implies
>some numbering of those seconds, which there is not - its an integral seconds
>duration.

I don't get the distinction you're making.  TAI does provide a labelling
of those seconds, as well as a basis on which to count them.  I'd favour
the note stating "TAI seconds" to distinguish it from UTC seconds and from
(theoretical ideal) SI seconds.

>The inconsistency resides in the 1588/PTP specification.

No, the PTP spec is consistent on this point.  Relevantly to what I said
above about using rubber UTC, the PTP spec is one of the rare cases of a
new document that needs to specify a precise time in the pre-1972 era.
It specifies it in more than one way, which is often a good strategy,
in that different representations can clarify each other.  One of the
ways used was UTC, and that's a somewhat confusing choice because rubber
UTC isn't otherwise relevant to PTP, but it is nevertheless a time
scale that is appropriate to the era involved, and it used correctly.
The inconsistency that you perceive is not between the PTP spec and
actual horological history; it is only between the PTP spec and your
personal imaginary version of pre-1972 UTC.

>         Essentially, the second part of the 1588/PTP epoch sentence, "...
>which is 31 December 1969 23:59:51.999918 UTC." and most of Annex B, except
>Table B.1, are just ignored.

I can easily believe that those parts of the spec are ignored by sensible
implementors, but that is not because of any error in them, nor because
paying attention to them would hinder computation.  It is because,
other than for the job of clarifying the primary statement of the epoch,
pre-1972 UTC is entirely irrelevant to PTP operations.

>gmtime(63072000) =  1972-01-01 00:00:00
>gmtime(0) =  1970-01-01 00:00:00
>gmtime(-10) =  FAILS

Really?  You have a crap version of gmtime() if it fails there.
glibc's gmtime happily returns 1969-12-31 23:59:50 for -10.

I'm not clear about the relevance of this part of your reply.
It initially looks as if you're trying to use the failure of gmtime() to
defend treating the nominal epoch as the unique earliest meaningful point
on a time scale, something discussed far above.  But I get some impression
that instead you're trying to use the results for these gmtime() calls
like you do the table in the NTP spec, to justify perceiving an absence
of pre-1972 leap seconds.  You're not clear about this.  If that's what
you're trying to do, it suffers exactly the same problem as your treatment
of the NTP table.  POSIX time, and Unix time in general, isn't really a
count of seconds, it's a count of days.  The differences between these
scalar values doesn't say anything about how long the days were.

-zefram