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
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
