Brooks Harris wrote: >On 2014-11-04 09:04 AM, Zefram wrote: >>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 -
The "note 1" that you quote doesn't make POSIX relevant to the definition of the PTP epoch. All it's pointing out is that the algorithm needed to convert between a PTP scalar value and a broken-down TAI time is identical to the POSIX-specified algorithm to convert between a time_t and a broken-down UTC time. Its wording is less than clear. >Annex B is a long detailed explanation of how PTP was (evidently) >designed to be compatible with POSIX. It sounds as though Annex B may contain actual errors, in such things as the interpretation of POSIX time_t. Good job it's not normative. >Well, I hope I haven't fallen into the confusion. You appear to have mistaken your pseudo-UTC for real UTC. You have been confused into thinking that the rubber-seconds era of UTC somehow poses a problem for PTP. >Not only my conclusion, and no more ridiculous than NTP' and POSIX's >similar use. NTP and POSIX do not imply anything about pre-1972 relationship between TAI and UTC. Both of them work exclusively with UTC, and it is no problem to them that their epochs lie in the rubber-seconds era (POSIX) or entirely prior to the existence of TAI and UTC (NTP). Scalar value differences in NTP and POSIX time_t depend only on the number of UTC days in the period in question, not on the number of leap seconds in the period. We've been through this before, around your CCT proposal. >OK. I'm using the term "proleptic UTC" is the same sense NTP >exrapolates date-time into the past. Not the same at all. NTP's proleptic UTC has an explicitly unknown leap schedule, because the leap schedule makes no difference to NTP. As a result, even though NTP explicitly refers to 1972 as the beginning of UTC, its proleptic UTC is actually entirely compatible with the real rubber-seconds UTC. Your "proleptic UTC" has a specific pre-1972 leap schedule, one which conflicts with the real pre-1972 UTC. >I would define it thus - > >Proleptic UTC - Unclear definition, as you don't address what should be the underlying reference time scale (taking the role of TAI). Bad name, because "proleptic UTC" is a description for a class of time scales. Even worse name because your time scale isn't even in this class: it isn't proleptic to (the whole of) UTC, it's only proleptic to *the leap-seconds era of* UTC. Also, as previously noted, an empty leap schedule makes a bad proleptic extension of any part of UTC. >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. As I noted above, the nature of the prolepsis for NTP and POSIX is qualitatively different from the prolepsis you're using to describe the PTP epoch as 1969-01-01T23:59:50Z. What you're using for PTP there isn't something taken from NTP or POSIX. I don't know whether you invented it; you're certainly not the *only* person to have invented it. As for naming it, in <mid:[email protected]> you referred to it using only the ISO 8601 "Z", implying UTC, and in <mid:[email protected]> you explicitly referred to it as "UTC". Only when pushed have you admitted that it's not actually UTC. You seem to think that it's somehow a uniquely correct proleptic extension of the leap-seconds era of UTC, which is far from the case. >> 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. As noted above, NTP and POSIX do not imply any specific proleptic leap schedule. Back in <mid:[email protected]> in the CCT thread I asked where you got the idea that NTP implies no leaps pre-1972, and you didn't answer. As best I can tell, you've looked at the scalar value differences, treated them as pure counts of TAI seconds, and concluded that they imply no leaps. But that logic would lead you to conclude that UTC *never* leaps. NTP scalar values and POSIX time_t values are not pure counts of seconds, but are defined to count 86400 per UTC day regardless of leaps. >>So, in summary, your pseudo-UTC is pointless, misrepresented, and >>defective. >I hope you'll reconsider that. My opinion stands. Your parallels with NTP and POSIX are erroneous, and your pseudo-UTC would still have the same faults even if it were also used by such other standards. >being used by some in the 1588/PTP community. Any suggestions as to >better clarify it accepted. I'd be happy to fully critique IEEE 1588, if someone were to provide me with a copy. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
