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. POSIX is irrelevant to this, and ISO 8601 merely provides the syntax to describe the approximate result. > 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. 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. Although I applaud the correctness, the PTP spec actually wins very little by including the UTC conversion. 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. 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. 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. > 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. 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. 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*). 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. Furthermore, you've invented a proleptic leap-seconds UTC *badly*. That 2 s difference between your proleptic UTC and the real UTC illustrates that yours is tracking UT1 poorly. This happens because (as with the CCT proposal) you've supposed that there are no leap seconds in the proleptic era. 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. So, in summary, your pseudo-UTC is pointless, misrepresented, and defective. -zefram _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs