[LEAPSECS] My FOSDEM slides
zefram at fysh.org
Sun Mar 8 15:43:33 EDT 2015
Brooks Harris wrote:
>On 2015-03-08 12:45 PM, Zefram wrote:
>>Brooks Harris wrote:
>>>In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
>>Where do you get this idea from? You've cited no source for it.
>>You appear to have plucked it from thin air.
>No, not from thin air, its very clear -
>IEEE Std 1588-2008, 7.2.3 UTC Offset - "...
>timePropertiesDS.currentUtcOffset = TAI - UTC."... "NOTE-As of 0
>hours 1 January 2006 UTC, UTC was behind TAI by 33 seconds."
That clause does not specify a currentUtcOffset value for 1969-12-31.
It gives a general definition, augmented with information that implies a
currentUtcOffset value for 2006-01-01 (of 33 s). I'm really not seeing
how you get from that to a value of 10 s for 1969-12-31. Taking UTC to
include the rubber seconds era gives a varying non-integral value near 8 s
for 1969-12-31. Alternatively, your view that the pre-1972 history isn't
`really' UTC implies that currentUtcOffset is undefined for 1969-12-31.
Only your fictitious UTC gives currentUtcOffset = 10 s for 1969-12-31.
If you're trying to use this statement as justification for your time
scale, then this is circular reasoning; you're begging the question.
>Right. But like the "rubber-band era" they are beside the point of
>timekeeping after 1972,
They would be beside the point if you hadn't raised the issue yourself.
You're expending a lot of effort on pre-1972 times that are all irrelevant
for this purpose. The actual time of the NTP epoch is beside the point.
>epoch, 1970-01-01T00:00:00 (TAI) is explicit only if you extrapolate
>proleptic TAI seconds prior to 1972-01-01 00:00:10 (TAI).
1972 is another date that doesn't mark the beginning of TAI. The name
"TAI" arose in 1971, but the BIH had actually been operating the service
in a pretty modern form for years. TAI times in 1970 are not proleptic.
>RFC 5905, Figure 4: Interesting Historic NTP Dates, shows this.
>| 1 Jan 1900 | 15020 | 0 | 0 | First day NTP |
>| 1 Jan 1972 | 41,317 | 0 | 2,272,060,800 | First day UTC |
>Thats 2,272,060,800 absolute seconds offset from the NTP prime epoch
>to 1972. 2272060800 / 86400 = 26297 exactly. There's no 10 second
>remainder. An initial TAI-UTC 10s offset is in effect at 1972 (by
>definition) so the seconds offset to the NTP prime epoch includes
>this, that is, the initial TAI-UTC 10s is in effect at the beginning
>of the NTP timescale.
You have misinterpreted that table. The heading of the column you're
referring to is "NTP Timestamp". There's no claim there that the
2272060800 is an actual number of seconds between two events. Rather,
2272060800 is the NTP scalar value describing 1972-01-01 00:00:00 UTC.
As you have repeatedly pointed out, NTP doesn't count leap seconds.
The difference between two NTP timestamps does not reflect the number
of leap seconds that occurred in that interval. The 2272060800 value
implies nothing at all about leap seconds between 1900 and 1972.
Also note the next entry in the table:
| 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th |
| | | | | Century |
This 3155587200 value is *also* an exact multiple of 86400. If it were
to be interpreted as a pure count of seconds, it would imply that there
were a total of zero leap seconds between 1900-01-01 and 1999-12-31, and
similarly a total of zero leap seconds between 1972-01-01 and 1999-12-31.
That would contradict the uncontroversial post-1972 leap second schedule.
>>But the NTP epoch is not so well defined. The NTP epoch is
>>not a specific point in time,
>Sure it is. The *the prime epoch, or base date of era 0, is 0 h 1
>January 1900 UTC"
1900-01-01 00:00:00 UTC is a fictitious timestamp, because UTC doesn't
extend back that far. The NTP epoch is, in that respect, fictitious.
> and is 2272060800 seconds before the "First day
And that's your misunderstanding of the NTP table again.
More information about the LEAPSECS