Brooks Harris wrote: >Meantime, the epochs of NTP and POSIX are defined in terms of "UTC", >but before 1972-01-01T00:00:00Z (UTC). They exist on a timescale I've >been flamed for calling "proleptic UTC". This a timescale that >extrapolates the Gregorian calendar counting method *uncompensated >for Leap Seconds or anything else* into the (indefinite?) past before >1972-01-01T00:00:00Z (UTC).
You have repeatedly made statements along these lines, but despite clear disagreement you have yet to justify this position. By "uncompensated for leap seconds" you apparently mean "not including leap seconds"; you are proposing a proleptic pseudo-UTC with an empty leap schedule. It appears to me that the definitions of NTP and POSIX time, and Annex B of IEEE 1588 which you've previously linked to this issue, are all silent on the leap schedule for pre-1972 UTC. Please explain how these documents all lead you to perceive a specifically empty leap schedule for pre-1972 pseudo-UTC. For example, in <mid:[email protected]> on 2014-08-27 you quoted the definition of NTP, RFC 5905: # 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. and then in the immediately following paragraph you wrote: |This describes a proleptic UTC timescale that is *uncompensated for |Leap Seconds*, that is, it extrapolates the Gregorian calendar |counting method into the past from 1972-01-01T00:00:00Z (UTC). I am at a loss to see how a standard that explicitly describes the leap schedule (of its explicitly fictitious pre-1972 UTC) as unknown leads you to say that it is describing a known empty leap schedule. This requires explanation on your part. How do you make this extraordinary leap of logic? Later, in <mid:[email protected]> on 2014-11-03, you said that table B.1 in IEEE 1588 (PTP), which describes relationships between various time scales, contradicts the use of rubber-seconds UTC. Elsewhere in the same message you said | 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. which uses motivation of rejecting rubber seconds to reach a conclusion of TAI-UTC at 1969-12-31 being not just integral but specifically exactly 10 s. You thus imply again a known empty leap schedule rather than an unknown leap schedule, let alone a known rubber schedule. But between the motivation and the conclusion you omitted to include any reasoning. How does IEEE 1588 lead you to perceive an empty 1969-to-1972 leap schedule? Later in the same thread I reviewed the actual text of IEEE 1588's Annex B, and found that the table of conversions is silent on pre-1972 UTC. You found this confusing, and so in <mid:[email protected]> I explained at great length how the conversion formulae don't supply a leap schedule but operate on whatever leap schedule the user cares to plug into them. I omitted on that occasion to turn the question round, but this seems a good point to do so: how do you find that table B.1 implies a specific leap schedule (pre-1972 or otherwise)? You wrote a bit about the origins of PTP and NTP being pre-1972, but that's irrelevant because the conversions don't operate on the origins (or anything else) as actual points in time. > (By the way, why is there no >accepted term for the idea of calendar date and time-of-day together, >I wonder?) I've used the term "calendar time". I guess that the lack of a common term is down to the two aspects of timekeeping having been developed fairly separately, and only recently (past couple of centuries) being frequently required to work together. > This because TAI is often also represented as a date-time >but there is rarely a clear distinction made about what it means. I find it perfectly clear. TAI ticks seconds that attempt to realise the SI second on the rotating geoid, and regular groups of 86400 consecutive seconds are bundled together and labelled as a day. The days themselves are labelled by means of MJDN or the calendar of one's choice, as if they were the solar days for which these labelling conventions were originally developed, but the link between the solar days and the TAI days is little more than notional. >ITU-R TF.460-6 says - >B International atomic time (TAI) >"... from the origin 1 January 1958 (adopted by the CGPM 1971)." > >What, do you suppose, does "1 January 1958" actually mean? It refers to the establishment of what we now call TAI, by means of a retrospective synchronisation such that 1958-01-01T00:00:00 TAI occurred at 1958-01-01T00:00:00 UT2(USNO), as best this could be determined at the time this was performed (late 1958). In the context of that clause, "1 January 1958" seems to refer specifically to that point on the TAI time scale: it's talking about counting the notional days, hours, minutes, and seconds *of TAI*. > I guess it >can't be on some "proleptic UTC" timescale because UTC doesn't yet >exist, so it must be on an uncompensated Gregorian calendar >timescale, I think. To the extent that it's referring to any time scale other than TAI, that time scale is UT2(USNO), or more loosely UT2 or vague UT. These time scales indeed don't have leap seconds, but their seconds are wildly rubbery. >So, how many (integral) seconds between 1958-01-01T00:00:00 (TAI) and >1972-01-01T00:00:00 (TAI)? > >1972-1958 = 14 years * 365 = 5110 days + 3 leap year days = 5113 days >* 86400 seconds = 441763200 seconds. Correct, with the proviso that this is specifically counting the seconds of TAI. The number of seconds of UT2, or in general any other time scale, would be different. >So now the tricky question - how many (integral) seconds between >1958-01-01T00:00:00 (TAI) and 1972-01-01T00:00:00Z (UTC)? Not at all tricky. That UTC time corresponds to a well-defined TAI time of 1972-01-01T00:00:10, and you ultimately come up with the correct answer of 441763210 seconds (again, TAI seconds). >http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat says - > ># MJD Date TAI-UTC (s) ># day month year ># --- -------------- ------ ># > 41317.0 1 1 1972 10 > >What, exactly, does this mean? Do we interpret the MJD value as >uncompensated Gregorian calendar, or should the conversion include >the 10 second initial offset somehow? What does "1 1 1972" mean, >exactly? 1972-01-01T00:00:00 (TAI) or 1972-01-01T00:00:00Z (UTC)? The date, given in both Gregorian and MJD forms, refers to the days of UTC. The TAI-UTC difference of 10 s came into effect at 1972-01-01T00:00:00 UTC. > Put another way, is the "UTC epoch" >1971-12-30T23:59:50 (TAI) = 1972-01-01T00:00:00Z (UTC)? I don't see how you could possibly reach this conclusion. This would involve TAI-UTC being -10 s, which is clearly not justified by the table entry. > Or should it >be represented as 1972-01-01T00:00:00 (TAI) = 1972-01-01T00:00:00Z >(UTC)? This too is silly, involving TAI-UTC = 0 s. If one were to interpret the date in the table as referring to the beginning of a TAI day, then one would come up with an epoch of 1972-01-01T00:00:00 TAI = 1971-12-31T23:59:50 UTC. That interpretation of the table would mean that leap seconds occur a few seconds before midnight, in the middle of a UTC minute, which would leave no unambiguous notation for them (23:59:60). So although the table isn't explicit about the dates being UTC, the knowledge that leap seconds occur at the end of a UTC day clarifies the matter. >I've seen many implementations that do not agree by 10 or 20 seconds, >indicating I'm not the only confused reader. I expect that a 10 s disagreement would arise from a leapless TAI-like time scale synchronised to UTC at 1972-01-01. That time scale amounts to TAI - 10 s, so mistaking it for TAI would lead to a constant 10 s error. The Olson `right' tzfiles are effectively based on using this time scale in the guise of time_t, so I wouldn't be too surprised at seeing it in the wild. I don't see where you'd get a 20 s disagreement from, but maybe you've seen a 19 s disagreement, which (ignoring nanosecond clock differences) is the constant difference between TAI and GPS time. GPS time was synchronised to UTC in 1980. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
