[LEAPSECS] My FOSDEM slides

Sun Mar 8 17:58:23 EDT 2015

On 2015-03-08 03:43 PM, Zefram wrote:
> 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
>>>> = 10s.
>>> 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.
That's what the explanations say, but not what real world 
implementations do.

> Alternatively, your view that the pre-1972 history isn't
> `really' UTC implies that currentUtcOffset is undefined for 1969-12-31.
As a practical matter its most convenient use currentUtcOffset = 10s at 
1970-01-01T00:00:00 (TAI) = "Zero PTP Time".

> Only your fictitious UTC gives currentUtcOffset = 10 s for 1969-12-31.

It not just my "fictitious UTC". That's how implementations are done. 
When you do it that way its easy, and everything is OK after 1972.

> 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.
>
>>                                                             PTP's
>> 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.

Yes, I know.

>
>> 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.

No no no! NTP, and this table, do not address Leap Seconds at all. 
That's the point of it! There are 3155587200 seconds from the epoch of 
*that* particular NTP timescale that includes "31 Dec 1999" - its epoch 
has slipped with respect to 1972UTC because the Leap Seconds are 
unaccounted for. All NTP days are 86400 long, as you point out. When the 
count freezes over a Leap Second the second offset to 1972UTC decreases 
by one.  That's the realization that hit me like a wave when I saw it.

There *are* zero leap seconds between [ 1900-01-01 *plus 22 forgotten 
Leap Seconds* ] and 1999-12-31.

That's what David Wells is trying to point out - read that again 
carefully -

David Wells writes:

The NTP Timescale and Leap Seconds
http://www.eecis.udel.edu/~mills/leap.html

3. How NTP and POSIX Reckon with Leap Seconds
"... the conversion is in effect reset to UTC as each broadcast timecode 
is received. Thus, when a leap second is inserted in UTC and 
subsequently in NTP or POSIX, knowledge of all previous leap seconds is 
lost."

"Another way to describe this is to say there are as many NTP or POSIX 
timescales as historic leap seconds. In effect, a new timescale is 
reestablished after each new leap second. Thus, all previous leap 
seconds, not to mention the apparent origin of the timescale itself, 
lurch backward one second as each new timescale is established. ..."

>>> 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.

Yes, of course. That's what NTP says, and that's what I'm saying. Its 
proleptic, I think is the correct word. I find it curious the word 
"proleptic" rarely appears in timekeeping specifications, when it is, in 
fact, the proper word for some things being described.

I guess you could call it "fictitious" if you want. But it seems like 
any numbering system is "fictitious" in that sense.

>
>>                   and is 2272060800 seconds before the "First day
>> UTC".
> And that's your misunderstanding of the NTP table again.

I don't think so.

-Brooks

>
> -zefram
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>