Hi Zefram,
>> Your focus on epochs is unhealthy.
I don't claim to be any more healthy than the many other folks I've had
these discussions with, most of whom are *obsessed* with, and *insistent
upon*, specifying a known *immovable* epoch.
I think I could characterize your focus on using "scalar values" as a
bit unhinged. :-)
The difference in our thinking seems to be my objective of placing the
various timescale epochs at fixed offsets from 1972-01-01T00:00:00Z
(UTC) = 1972-01-01T00:00:10Z (TAI) v.s. yours that allows the epochs to
slip with each Leap Second in the manner NTP and POSIX do, which is, as
you call it, "scalar".
Indeed, I think one of the reasons many people feel the need to use a
"TAI-like" timescale is that generally those timescale's epochs are
*fixed*, whereas with the NTP and POSIX implementations of "UTC-like"
timescales, the epochs *slip*, essentially creating a new timescale with
a different epoch offset to 1972-01-01T00:00:00Z (UTC) =
1972-01-01T00:00:10Z (TAI) with each Leap Second.
I've actually tried to answer your earlier emails but each time it's
turned to a multi-page essay and I never quite completed it. I'll try to
finish that, but here I'll try to quickly answer your comments.
On 2015-03-05 01:29 PM, Zefram wrote:
Brooks Harris wrote:
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.
It's correct to the microsecond precision given. My only real correctness
concern there is that it implies an exact equivalence which there isn't.
However, it is somewhat misleading by virtue of failing to explicate that
it is using the rubber-seconds UTC which is otherwise irrelevant to PTP.
Yes, it is "otherwise irrelevant to PTP". Thats my point. All the
discussion about the rubber-band period and use of "the POSIX algoritm"
is beside the point for practical implementation, and hence, only a
misleading distraction.
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
...
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
No, there is no contradiction there. The table makes no claim about
the correspondence between TAI and UTC at any particular point in time.
It does if your objective is to link PTP time to the fixed epoch of
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI), to the NTP prime
epoch of era 0, and to the POSIX "the Epoch".
It can *also* be interpreted as scalar offsets, as you are interpreting
them, yes, if that's how you need to use them.
It makes correct claims about the correspondences between various scalar
representations of time. The only subtlety is the "currentUtcOffset" term
in the PTP<->NTP equations. The currentUtcOffset (meaning (TAI-UTC)/s)
is not defined for all points in time, and during the rubber-seconds
era of UTC it takes on non-integral values.
Not in a practical timescale implementation. The "rubber-band era" is
just entirely irrelevant. Its historically interesting, and may be
required for some special application concerning that period, but for
practical "UTC-like" timekeeping its just an historical curiosity.
This fact is somewhat more apparent looking at the IERS publication
Leap_Second_History.dat, at
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we
see *no values* before "1 1 1972" - the "rubber-band era" is gone.
That's correct - the "rubber band era" no long exists.
[By the way, I think this document is the most well formed information
about TAI/UTC. By using MJD there is no mistaking on what day each Leap
Second occurs. I haven't found any official information at IERS about
the policies of this document's publication but I think this may be the
best source of official Leap Second information available. Note it
includes the upcoming 2015-07-01 Leap Second.]
In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset =
10s.
PTP time does not exist before this date-time. Official TAI exists from
the origin of 1958-01-01T00:00:00 (TAI). "Integral second UTC" didn't
exist before 1972-01-01T00:00:00Z (UTC). Thats where you need a
timescale that is an integral second measure proleptic to
1972-01-01T00:00:00Z (UTC), the timescale I keep trying to explain. With
that, the PTP epoch is 1970-01-01T00:00:00 (TAI) = 1969-12-31T23:59:50Z
(UTC).
By the way, I think its unfortunate they didn't specify the epoch as
"1970-01-01T00:00:10 (TAI)" (note the 10s) because then it would
coincide exactly with POSIX "the Epoch". As it is there's a 10s
difference between them. Thus, more complexity and potentially more
confusion.
This obviously can be a bit
confusing, because for the purposes of PTP as an operational protocol,
in which context only current timestamps are relevant, currentUtcOffset
is always well-defined and integral.
Yes.
For the purposes of table B.1 it
is not.
I think you mean if you are attempting to map into the "rubber-band era"
you could interpret the currentUtcOffset value to be non-integral, but
that's not explicit in the table. In fact I see currentUtcOffset as
being defined as integral seconds. In any event, any consideration of
the "rubber-band era" is just not relevant, as above.
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
I don't think you've succeeded in defining a particular time scale here.
Your previous messages, and the table and comments later in your present
message, suggest that you're thinking of a time scale that amounts to TAI
- 10 s prior to 1972. But the phrases "Gregorian calendar timescale"
and "treats the measurement unit as integral seconds" don't seem to
actually imply that. I can't make much sense of either phrase.
I'm going to need to work on this explanation some more, which I'll try
to do, but I need to get this respond off my desk. Perhaps part of
understanding what I'm saying is clarified in the topic of "fixed epoch"
v.s. "scalar".
With that you can reconcile the offsets between the epochs of NTP,
TAI, PTP, POSIX, UTC, and GPS in integral seconds.
Your focus on epochs is unhealthy.
I could say, for purposes of precision timekeeping, it is unhealthy to
focus on "scalar values" - "fixed epoch" is more appropriate. Hence my
joke about calling you unhinged :-)
Some of the epochs don't unambiguously
correspond to particular points in time, and in context that's not
a problem.
I'd say it *is* a problem. I think you mean "in context" of mapping to
conventional timekeeping mechanisms like NTP and POSIX. It is true in
those "the epochs don't unambiguously correspond to particular points in
time". But that's exactly the issue I'm trying to point out - everything
is slipping around in many conventional timekeeping systems.
Notice that table B.1 that you quoted doesn't make any
reference to epochs per se: it doesn't describe relationships between
epochs,
I think it does.
"NTP Seconds = PTP Seconds + 2 208 988 800 ─ currentUtcOffset" describes
the absolute seconds offset from the NTP prime epoch era 0 to the PTP
Epoch. If your implementation is to keep those reference points fixed,
that tells you the constant offset.
it describes relationships between *scalar values*.
That too, if that's your need and how you treat those values.
What matters
is that these scalar values correspond to specific points in time over the
time period that matters for the application. Scalar value zero isn't
inherently part of the relevant time period. Taking NTP in particular,
no one was running NTP in 1900, so it is of no significance that NTP
zero doesn't correspond to a specific point in time.
I think that is exactly at the root of the entire difficulty with the
"Leap Seconds" conversation. We understand both NTP and POSIX are flawed
with respect to Leap Seconds and UTC because their counting mechanisms
cannot count to 23:59:60. Thus, each Leap Second *slips the epoch*, so
"seconds from the epoch" is always the number of "Leap Seconds in
effect" short, in essence creating many separate timescales.
>> no one was running NTP in 1900,
Of course not. But its conceptual timescale is in use everywhere.
I have constructed an implementation of an experimental reference
timescale with fixed epoch offsets starting at 1900-01-01T00:00:00Z
(UTC) = 1900-01-01T00:00:10 (TAI). This spans all the interesting epochs
- NTP, TAI, PTP, POSIX, UTC, and GPS. I can map this to correct
representations on any of those timescales (of course NTP and POSIX
repeat or over-count the Leap Seconds), and confirmed this with
reference to Windows Systemtime, the MSVC implementation of POSIX time_t
etc, and verified against an implementation of SNTP. To do this you need
a complete Leap Seconds table, of course. Having an official method of
obtaining those values automatically is a big missing peice of the UTC
specs in general, and the subject of other threads on the LEAPSECS list.
The counting mechanisms of NTP and POSIX are ubiquitous in OSs, systems,
and languages. So, the thought process about UTC and Leap Seconds is
understandably focused on resolving the differences between NTP/POSIX
and proper UTC. That, I think, is where your "scalar" mapping point of
view comes from. And I agree, that approach is necessary to map UTC to
NTP and POSIX.
But fundamentally, NTP and POSIX *cannot possibly work correctly* where
proper UTC is concerned because the 23:59:60 count just goes missing.
Yes, it can be made to work for most date-times if you're careful -
that's whats going on today. But it can't represent the Leap Second
itself (23:59:60 and potentially the rollover at 23:59:58), so its
counting mechanism is basically *incomplete* and durations are
ambiguous. That's not "precision timekeeping". The insertion of Leap
Seconds upsets the apple cart because it introduces complexity, and in
some cases confusion, into the implementations, and so, potentially, *bugs*.
I'm sure you'll give me a chance to further explain myself and my
unhealthy views :-)
-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
