Brooks Harris wrote: >that allows the epochs to slip with each Leap Second in the manner >NTP and POSIX do, which is, as you call it, "scalar".
I think you understand by the word "scalar" something very different from what I mean. By "scalar value" I mean a value consisting of a single number, such as a Unix time_t value or an NTP time value. Non-scalar time values include anything that separates date from time-of-day. > whereas with the NTP and POSIX implementations of "UTC-like" >timescales, the epochs *slip*, essentially creating a new timescale >with a different epoch This is a legitimate view of the NTP and POSIX systems, which has a certain amount of theoretical value. >On 2015-03-05 01:29 PM, Zefram wrote: >>Brooks Harris wrote: >>No, there is no contradiction there. The table makes no claim about >>the correspondence between TAI and UTC at any particular point in time. >It does if your objective is to link PTP time to the fixed epoch of No, your objective doesn't fundamentally change what the table says. >> The currentUtcOffset (meaning (TAI-UTC)/s) >>is not defined for all points in time, and during the rubber-seconds >>era of UTC it takes on non-integral values. > >Not in a practical timescale implementation. If your concept of a "practical timescale implementation" excludes rubber-seconds UTC, then sure, rubber-seconds UTC doesn't arise in your "practical timescale implementation". That still doesn't change what happens when one *does* consider rubber-seconds UTC. You wishing that it didn't exist doesn't make it go away. >In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset >= 10s. Where do you get this idea from? You've cited no source for it. You appear to have plucked it from thin air. > Official TAI exists >from the origin of 1958-01-01T00:00:00 (TAI). That's a misunderstanding of the nature of the TAI `epoch'. It is not the case that TAI existed from the epoch onwards and did not exist before. TAI has existed to varying degrees from mid-1955 onwards, and historically nothing special happened to it on 1958-01-01. That date only became special in retrospect, in late 1958. That's when the time scale was established in a form that we'd recognise (though not with its present name), counting units of atomic seconds and labelling them by MJD and equivalents. The specialness of 1958-01-01 is merely that those MJD labels were aligned such that TAI coincided with UT2(USNO) on that date. TAI timestamps in early 1958 are necessarily retrospective (more so than TAI timestamps from 1959 onwards are), and such retrospective TAI timestamps can be applied all the way back to the start of continuous atomic clock operations in 1955. Are you just making an arbitrary decision that TAI from 1958 onwards is "official" (even where retrospective) and that TAI prior to 1958 is "not official" (even where well defined)? If you are choosing an arbitrary cutoff for the purposes of your project, you should be explicit about that scope and about its arbitrariness. > Thats where you need >a timescale that is an integral second measure proleptic to >1972-01-01T00:00:00Z (UTC), the timescale I keep trying to explain. >With that, the PTP epoch is 1970-01-01T00:00:00 (TAI) = >1969-12-31T23:59:50Z (UTC). In addition to the very dubious nature of the "need" for a specific proleptic extension of integral-seconds UTC, you here make the jump from *a* proleptic integral UTC to *the* time scale you are constructing. There are many possible proleptic extensions of integral-seconds UTC, and you have consistently failed to explain why one must specifically use the one that has no pre-1972 leap events. >By the way, I think its unfortunate they didn't specify the epoch as >"1970-01-01T00:00:10 (TAI)" (note the 10s) because then it would >coincide exactly with POSIX "the Epoch". It would coincide exactly only in the context of your fictitious leap-seconds-but-no-actual-leaps pre-1972 UTC. Given the fundamental differences between PTP and POSIX time values, having the epochs coincide to any appreciable degree invites confusion. Having them as close as they are (about 8 s using real UTC, 10 s using your fictitious UTC) is bad enough; getting them as close as 2 s (and especially the exact coincidence with your fictitious UTC) would be asking for trouble. >I think you mean if you are attempting to map into the "rubber-band >era" you could interpret the currentUtcOffset value to be >non-integral, but that's not explicit in the table. Indeed, that's not explicit. It's implied by the basic definition of currentUtcOffset (as the difference between TAI and UTC) combined with the fundamental behaviour of rubber-seconds UTC. > In fact I see >currentUtcOffset as being defined as integral seconds. The protocol field is defined to only accommodate integral values, but annex B clearly looks at the theory beyond the scope of the actual protocol. The integral nature of the field means that it's impossible to handle rubber-seconds UTC by running PTP. This will not be a problem until a copy of IEEE 1588 falls through a wormhole into the 1960s. >"NTP Seconds = PTP Seconds + 2 208 988 800 - currentUtcOffset" >describes the absolute seconds offset from the NTP prime epoch era 0 >to the PTP Epoch. The phrases "NTP Seconds" and "PTP Seconds" clearly refer to the scalar values used in those protocols. The table is directly describing a relationship between those scalar values, and does not mention epochs at all. > If your implementation is to keep those reference >points fixed, that tells you the constant offset. If the epochs were both well defined, in such a way that each could be meaningfully represented on the other protocol's time scale, then the relationship between the scalar values would be sufficient to perform this conversion and potentially determine a time offset between the epochs. But the NTP epoch is not so well defined. The NTP epoch is not a specific point in time, and so cannot be converted into the PTP time scale. It couldn't be so converted even if the PTP time scale extended back to 1900, which it doesn't. >I have constructed an implementation of an experimental reference >timescale with fixed epoch offsets starting at 1900-01-01T00:00:00Z >(UTC) = 1900-01-01T00:00:10 (TAI). Once again, you should not use the labels "TAI" and "UTC" for such timestamps. Where you have invented time scales, use distinctive labels for them. Don't claim that they're the actual TAI and UTC. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
