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@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
