[LEAPSECS] My FOSDEM slides

[Brooks Harris]

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 at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>