On 2015-03-05 08:39 AM, Martin Burnicki wrote:
Tony Finch wrote:
Martin Burnicki <[email protected]> wrote:
I agree, but as I've tried to point out above I think a better
project design
would have been to use TAI instead of GPS time. PTP works natively
with TAI,
and you can easily convert between he two scales.
I don't understand this paragraph. The three timescales you mention have
totally different formats:
TAI: YYYY-MM-DD T HH:MM:SS
PTP: SSSSSSSSSS
GPS: WWWW SSSSSS
They have different epochs:
TAI: 1958-01-01 T 00:00:00 Z
PTP: 1970-01-01 T 00:00:00 Z
GPS: 1980-01-06 T 00:00:00 Z
So I don't see how it makes sense to argue that PTP is more like TAI
than
GPS time.
In the strict scientific sense I agree.
However, in practice, and for "current" dates, you can convert each of
them to a number of seconds since the epoch, and for practical
purposes the difference is just an integral number of seconds.
I agree.
We have seen the casual term "TAI-like", meaning an "uninterrupted
incrementing count of seconds" from some epoch. PTP and GPS are
"TAI-like" in that sense.
For example, the IEEE Std 1588-2008 says:
"The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December
1969 23:59:51.999918 UTC"
However, the time stamps used in the PTP packets are just binary
numbers of seconds, and you have to apply an integral number of
seconds to convert this to UTC.
Yes, that's how it must be treated.
I urge caution interpreting the meaning of the PTP Epoch as stated in
the spec.
The first part of that sentence is correct "The PTP epoch is 1 January
1970 00:00:00 TAI". But the second part, "which is 31 December 1969
23:59:51.999918 UTC", is not, or, is at least very misleading.
This of course begs the all questions regarding a "proleptic UTC"
timescale. What, exactly, is that? Did it exist before
1972-01-01T00:00:00Z (UTC)? Does it include the "rubber-band era"
between approximately 1961 and 1972?
The spec goes through long explanations of the relation of its epoch to
the "POSIX algorithm". It wanders through explanation of the
"rubber-band" era, and how the "broken down time" results are obtained
from gmtime(). This is all wicked confusing. Apparently the IEEE PTP
committee took "UTC" to include the "rubber-band era", and so attempted
to reconcile the PTP epoch to it.
In an *informative* Annex B - Timescales and epochs in PTP, there is
further (confusing) explanation, but then comes Table B.1?Relationships
between timescales. There we find -
Table B.1?Relationships between timescales
From | To | Formula
NTP Seconds | PTP Seconds | PTP Seconds = NTP Seconds ? 2 208
988 800 + currentUtcOffset
PTP Seconds | NTP Seconds | NTP Seconds = PTP Seconds + 2 208
988 800 ? currentUtcOffset
GPS Seconds = | |
(GPS Weeks | |
× 7 × 86 400) | |
+ GPSSecondsInLastWeek| |
(GPS week number must | |
include 1024 × number | |
of rollovers) | PTP Seconds | PTP Seconds = GPS Seconds + 315
964 819
PTP Seconds | GPS Seconds | GPS Seconds = PTP Seconds ? 315
964 819
All the values in this table are *integral seconds* and they are correct
with respect to the definitions other timescale Epochs. (They neglect to
say the values for NTP are to NTP's "prime epoch of era 0", a subtle but
important point)
These are the values you must use for a practical implementation of PTP,
and that is the convention adopted by the PTP community. These values
*contradict* the second part of the epoch specification sentence
("...which is 31 December 1969 23:59:51.999918 UTC") and all the rest of
the PTP epoch explanations throughout the document.
The "rubber-band era", while historically important, is just not
relevant to practical timekeeping applications concerned with modern UTC
and "civil time". The scattered nature of the UTC specifications lead
from UTU-R Rec 460 to BIPM Annual Report on Time Activities Tables 1 and
2 that list the historical values of the "rubber-band era". This leads
to attempting to figure out what the historical values of UTC were
during this period. Its interesting, but its a huge distraction until
you realize it doesn't matter for most purposes. Like many of us, the
IEEE PTP committee fell into this trap.
You can construct a Gregorian calendar timescale that is proleptic to
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) (note the 10s
TAI/UTC offset) and treats the measurement unit as integral seconds.
This is, I believe, is the timescale most often used to calculate
offsets between timescales, but is never explicitly acknowledged or
named. Here I'll name it "Gregorian proleptic to UTC1972".
With that you can reconcile the offsets between the epochs of NTP, TAI,
PTP, POSIX, UTC, and GPS in integral seconds.
-----------------------------------------------------------------------------------------
Origin | UTC1972 | Coincides | UTC |Leap| TAI
Name | Seconds | with | |Secs|
| Offset | Origin of | ( Earth )
| | | (Correction)
| | | | |
-----------------------------------------------------------------------------------------
UTC1900 | -2272060800 | NTP | 1900-01-01T00:00:00Z | 10 |
1900-01-01 00:00:10
TAI1958 | -441763210 | TAI | 1957-12-31T23:59:50Z | 10 |
1958-01-01 00:00:00
TAI1970 | -63072010 | 1588/PTP | 1969-12-31T23:59:50Z | 10 |
1970-01-01 00:00:00
UTC1970 | -63072000 | POSIX | 1970-01-01T00:00:00Z | 10 |
1970-01-01 00:00:10
TAI1972 | -10 | UTC + 10s | 1971-12-31T23:59:50Z | 10 |
1972-01-01 00:00:00
UTC1972 | 0 | UTC | 1972-01-01T00:00:00Z | 10 |
1972-01-01 00:00:10
UTC1972_7_1 | +15724800 | First Leap | 1972-07-01T00:00:00Z | 11 |
1972-07-01 00:00:11
UTC1980_1_6 | +252892800 | GPS Epoch | 1980-01-06T00:00:00Z | 19 |
1980-01-06 00:00:19
On this timescale, for practical implementations, the PTP Epoch,
1970-01-01T00:00:00 (TAI) aligns with 1969-12-31T23:59:50 (Gregorian
proleptic to UTC1972), *not* 31 December 1969 23:59:51.999918 UTC.
-Brooks
Similarly, the comments in the NIST leap second file say:
# The second column shows the number of seconds that
# must be added to UTC to compute TAI for any timestamp
# at or after that epoch.
Even though the number of seconds between TAI and GPS timestamps is
constant, if you use all the scales TAI/GPS/UTC in an application you
have to do more different conversions than if you had only TAI and UTC.
Just imagine a PTP grandmaster, controlled by a GPS receiver which
outputs raw GPS time.
Tony, I'm sure you know all of the above, but I just wrote this to
make clear what I meant.
Martin
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
