[LEAPSECS] the big artillery

[Brooks Harris]

Hi Zefram,

On 2014-11-04 09:04 AM, Zefram wrote:
> Brooks Harris wrote:
>> The discussion attempts to resolve the question about what the
>> TAI/UTC relationship was *before* 1972-01-01T00:00:00Z and how this
>> is related to POSIX and represented by 8601.
> The actual historical relationship between TAI and UTC prior to 1972
> is defined by the well-known tai-utc.dat file.  1970-01-01 falls within
> the rubber-seconds era of UTC, and the file gives the expression
>
> 	TAI-UTC=   4.2131700 S + (MJD - 39126.) X 0.002592 S
>
> Applying this, we find that 1970-01-01T00:00:00 TAI was approximately
> 1969-12-31T23:59:51.9999 UTC.  The fractional part of the seconds value is
> exactly 99991827/100000003 (which can't be expressed in ISO 8601 syntax).
> That's the PTP epoch expressed in the actual historical UTC; no other
> value is correct.
Perhaps, but as I said before, I am advised by PTP people that A) Yes, 
the spec is confusing, and, B) that most of the PTP community does NOT 
use it that way, rather, they use the integral second interpretation as 
shown in the (informative) 1588/PTP Annex B, Table B.1.

I didn't make this up. And, as I said earlier, I fear there are 
incompatible 1588/PTP implementations the field due to this confusion.

> POSIX is irrelevant to this,
I don't think so. 1588/PTP references POSIX and "(POSIX) algorithms" 
many times, first in the main definition of the PTP Epoch -

7.2.2 Epoch -

NOTE 1— The PTP epoch coincides with the epoch of the common Portable 
Operating System Interface (POSIX) algorithms for converting elapsed 
seconds since the epoch to the ISO 8601:2004 printed representation of 
time of day; see ISO/IEC 9945:2003 [B16] and ISO 8601:2004 [B17].

NOTE 2— See Annex B for information on converting between common timescales.

Annex B is a long detailed explanation of how PTP was (evidently) 
designed to be compatible with POSIX. But, as above, many 
implementations have bypassed that aspect of the specification.

> and ISO 8601 merely
> provides the syntax to describe the approximate result.
Sure. And that has limitations, of course.
>
>>                                                the term "UTC" may or
>> may not be applicable to date-time before 1972
> Many things referring to "UTC" only address the leap-seconds era, and
> so don't apply pre-1972.
Sure.
> The PTP spec's conversion of its epoch to UTC
> is one of the relatively rare cases of actually engaging with pre-1972
> UTC and using it correctly.  So in this case the term does apply.
Yes, they did, but, again, that historical record is often ignored.
>
> Although I applaud the correctness, the PTP spec actually wins very
> little by including the UTC conversion.
Indeed.

> As previously discussed in the
> context of your CCT proposal, PTP never actually processes timestamps
> anywhere near its origin: it suffices to define the relationship between
> PTP scalar values and TAI only for current times.
True for most "civil-time" related timescales.
> Defining the epoch
> as 1970-01-01T00:00:00 TAI is in itself a neat way of defining the
> relationship, but the conversion to UTC is much less neat.
>
> Presumably the intent of the conversion was to clarify the specification
> of the epoch.  For me it succeeds in that, because I recognise the two
> expressions as describing almost the same time (within a microsecond),
> and this clarifies that where the spec says "TAI" it really means it.
Yes, it does help in that respect I suppose. But it might have sufficed 
to say "TAI, and we really mean it".

> However, by sowing the confusion into which you have fallen, it seems
> that the clarification is counterproductive for readers not familiar
> with rubber-seconds UTC.
Well, I hope I haven't fallen into the confusion. Indeed, I've witnessed 
long efforts and debates as to how to cope with the historical record 
(pre 1972). I've wrangled with it myself. The 1588/PTP specification is 
the most elaborate of these I've seen, and arguably the most correct. 
But I'd say they and others have fallen into this confusion because the 
only practical approach is to discard, or ignore, that period and paper 
it over with some "proleptic UTC" (more on that below).

>
>>                            The conclusion is that the PTP Epoch is
>> 1970-01-01T00:00:00 (TAI) which *must be treated as*
>> 1969-12-31T23:59:50Z (UTC), *not* "1969 23:59:51.999918 UTC" as
>> stated in the 1588/PTP document. The reason is to maintain an
>> integral-second alignment between the PTP Timescale and the UTC
>> timescale.
> That's a ridiculous conclusion.
Not only my conclusion, and no more ridiculous than NTP' and POSIX's 
similar use.
> Integral-second alignment between
> the PTP timescale (effectively TAI) and UTC, for the pre-1972 era, is
> irrelevant, because no one actually used PTP in that era.
Right. But for a coherent mapping between timescales we need to anchor 
them to some epoch and define their counting methods.

> It's also
> impossible to achieve with the real UTC, both because UTC and TAI had
> a frequency offset in that era (so a UTC second isn't an integral TAI
> second) and because of the irregular leap at the end of 1971 (so that
> there weren't an integral number of UTC seconds between second-aligned
> UTC times -- it's not aligned with *itself*).
Right. So ignore that era.

>
> Your "treating it as" a second-aligned UTC time amounts to inventing a
> fictitious proleptic leap-seconds UTC.  It's not wrong to invent such
> a beast, but it is wrong to call it "UTC" without qualification, as you
> did earlier in this thread (and as you also did in the initial version
> of your CCT proposal).  You should always explicate when you're using
> such a non-standard time scale.
OK. I'm using the term "proleptic UTC" is the same sense NTP exrapolates 
date-time into the past. They don't use the term "proleptic", but do use 
the term "UTC" for their proleptic extrapolation. To quote NTP - RFC 
5905, 6. Data Types

" In the date and timestamp formats, the prime epoch, or base date of
era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should
be noted that strictly speaking, UTC did not exist prior to 1 January
1972, but it is convenient to assume it has existed for all eternity,
even if all knowledge of historic leap seconds has been lost."

I would define it thus -

Proleptic UTC - An extrapolation of the Gregorian calendar counting 
method (as codified in ISO 8601) into the indefinite past from 
1972-01-01T00:00:00Z (UTC). There is no Leap Second or any other 
compensation applied. It is an artificial construct for the convenience 
of calculation. Any date-time representation prior to 
1972-01-01T00:00:00Z (UTC) is inaccurate.

On this proleptic UTC timescale, NTP picked 1900-01-01T00:00:00Z 
(proleptic UTC) as its (era 0) epoch, POSIX, 1970-01-01T00:00:00Z 
(proleptic UTC), and 15888/PTP, 1969-01-01T23:59:50Z (proleptic UTC). I 
really didn't make something new up - I just gave the idea a name.

>
> Furthermore, you've invented a proleptic leap-seconds UTC *badly*.
No more badly than NTP and POSIX.
>   That 2
> s difference between your proleptic UTC and the real UTC illustrates
> that yours is tracking UT1 poorly.
Purposefully, like NTP and POSIX.

>    This happens because (as with the
> CCT proposal) you've supposed that there are no leap seconds in the
> proleptic era.
Correct. Same as NTP and POSIX.
>   If you're going to have a proleptic leap-seconds UTC,
> you need to schedule some proleptic leap seconds to maintain tracking.
> For example, Tony Finch's proleptic leap-seconds UTC (pUTC, extending
> back to 1958-01-01) has leaps at 1971-06-30 and 1970-06-30, so the PTP
> epoch is exactly 1969-12-31T23:59:52 pUTC.  You do get integral-seconds
> alignment between TAI and pUTC.
Yes, I've tried that, and its interesting from an historical 
perspective. But its not helpful to timekeeping after 1972, as you point 
out above.

>
> So, in summary, your pseudo-UTC is pointless, misrepresented, and
> defective.
I hope you'll reconsider that. Its just like NTP, and its how its being 
used by some in the 1588/PTP community. Any suggestions as to better 
clarify it accepted.

-Brooks

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