Brooks Harris wrote:
>There is a hole in the data of these tables; Rec 460 tells us the origin of
>TAI is "1 January 1958" but the first TAI-UTC value listed in the tables is
>in 1961 - what happened between 1958 and 1961?
You've previously shown some confusion along these lines, and I think
the origin of it is becoming clearer. You've erred by trying to treat
TAI and UTC as a closely-tied pair, in particular trying to apply the
same threshold dates to them. One would think that it would be easy to
grasp that different time scales each have their own epoch. It sounds
like you've gone into this with a preconceived notion that the entirety of
modern horology sprang into existence at a single instant. You're having
difficulty in abandoning this preconception in the face of evidence.
>In the end the only sensible thing to do is ignore these obsolete facts and
>establish a proleptic integral-second timescale. That's exactly what NTP
>does,
No, that's not a particularly sensible thing to do, and it's not what
NTP does. NTP is silent on how UTC behaved prior to the existence
of NTP, and that *is* a sensible approach for any system that's only
concerned with present times. The same applies to the use of PTP: one
need not take any position on how UTC or even TAI behaved prior to the
21st century. The PTP epoch only need be defined sufficiently to give
meaning to current PTP timestamps.
>1588 states "7.2.2 Epoch - The PTP epoch is 1 January 1970 00:00:00 TAI,
>which is 31 December 1969 23:59:51.999918 UTC.". (This is consistent with
>Steve's statement above - "At 1970-01-01 the difference TAI - UTC(BIH) was
>8.000082 SI seconds."). However, this seems in conflict with Annex B, Table
>B.1 - Relationships between timescales, one entry of which says "NTP Seconds
>= PTP Seconds + 2 208 988 800 - currentUtcOffset".
There is no conflict. The table entry is perfectly correct, over the
range of times for which all the terms are defined. If one engages in
the dubious exercise of applying NTP and PTP concepts to a time as early
as 1969, even then the equation is correct. At the instant of the PTP
epoch, we have
NTP Seconds ~= 2208988791.99918
PTP Seconds = 0
currentUtcOffset ~= 8.000082
all of which is consistent with the equation. The only part of this
that is at all problematic is currentUtcOffset being non-integral, which
cannot be represented in the PTP protocol. That means that it would be
difficult to actually use PTP in 1969, but there are a couple of other
difficulties there that overshadow this one. Note that, with respect to
such historical application of the concepts, PTP's Annex B explicitly
says "Prior to 1 January 1972, corrections to the offset between UTC
and TAI were made in fractions of a second.".
If the fractionality were to somehow cause a real problem -- and I'm
failing to see the use case for which this would occur with respect
to PTP -- one could use a proleptic extension of leap-seconds UTC,
such as Tony Finch's pUTC. This would round off the above numbers.
pUTC would give, for the PTP epoch:
NTP Seconds = 2208988792
PTP Seconds = 0
currentUtcOffset = 8
This is no longer consistent with real UTC history, but it does permit
current PTP-related code to think about 1969. Of course, there's no
reason to stop there: if one wants PTP code to think about 1969, then
why not 1929 too? There's nothing special about the PTP epoch from this
point of view.
Returning for a moment to the subject of your (Brooks's) psychology, you
grant epochs a huge unjustified significance. You seem to think, despite
any actual application requirements, that it is essential for modern
code in any of these systems to be able to operate in the region where
time is represented by a scalar value of zero (i.e., at the protocol's
nominal epoch). By implication, you seem to also think that this code
does not need to be able to operate on any earlier time. It is quite
bizarre to use the nominal epoch as this threshold of applicability.
You need to use different thresholds for different purposes, choosing
each threshold appropriately based on the uses to which it will be put.
> If date-time before 1972 UTC is treated as integral seconds
>the same way NTP and POSIX define their origins the PTP epoch is 1970-01-01
>00:00:00 (TAI) = 1969-12-31T23:59:50 (UTC).
No, that doesn't follow. If you apply a fictitious UTC which is
always an integral number of seconds offset from TAI, then, within this
counterfactual universe, it necessarily follows that in 1969 the TAI-UTC
offset was integral. It does not follow that it was exactly 10 s.
One has a fairly free choice in what offset to apply to any particular
pre-1972 time, but some choices are clearly better than others. 10 s
is a poor choice for the second half of 1969, because it means that the
UT1-UTC difference is well beyond its modern bounds, despite it being
very easy to keep it in bounds. 8 s is the only option for December
1969 that keeps UT1-UTC within the modern bound.
Also, NTP and POSIX don't imply this kind of pre-1972 UTC. They're both
silent on the issue.
>The SMPTE Epoch shall be 1970-01-01T00:00:00TAI, which is the same as the PTP
>Epoch specified in IEEE
>Standard 1588-2008.
>
>Note: The SMPTE Epoch is 63072010 seconds before 1972-01-01T00:00:00Z (UTC).
This too does not have the implication that you state. It specifies
an epoch in three ways, all of which agree with each other, and which
do not require one to take any position on pre-1972 UTC. The only use
of UTC here is to specify a time that uncontroversially corresponds to
1972-01-01 00:00:10 TAI. The SMPTE Epoch that the passage describes lies
exactly 63072010 TAI seconds before that instant. (It's not 63072010
UTC seconds, and the note would be clearer if it specified "TAI seconds"
rather than just "seconds".)
> the SMPTE
>"note" says, and the intention is it be, 1969-12-31T23:59:50 (UTC).
No, it doesn't say that. It doesn't say anything about the UTC
representation of the SMPTE Epoch. Hypothetically, if it did state
"1969-12-31 23:59:50 UTC" then that would be a problem, because it would
be inconsistent with the other ways in which the SMPTE Epoch is specified.
In any proleptic UTC-with-leap-seconds that covers that period,
those 63072010 seconds *would* be 63072010 pseudo-UTC seconds, due
to pseudo-UTC seconds being identical to TAI seconds by stipulation.
It would be this many pseudo-UTC seconds regardless of the leap schedule
of the pseudo-UTC. Even in this situation, the passage still doesn't
say anything about the (pseudo-)UTC representation of the SMPTE Epoch.
It would be a second-aligned pseudo-UTC time, of course, but not
necessarily 23:59:50, and indeed for it to be that would imply poor
tracking of UT1 by the pseudo-UTC.
-zefram
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
