[LEAPSECS] My FOSDEM slides

[Zefram]

Brooks Harris wrote:
>that allows the epochs to slip with each Leap Second in the manner
>NTP and POSIX do, which is, as you call it, "scalar".

I think you understand by the word "scalar" something very different from
what I mean.  By "scalar value" I mean a value consisting of a single
number, such as a Unix time_t value or an NTP time value.  Non-scalar time
values include anything that separates date from time-of-day.

>         whereas with the NTP and POSIX implementations of "UTC-like"
>timescales, the epochs *slip*, essentially creating a new timescale
>with a different epoch

This is a legitimate view of the NTP and POSIX systems, which has a
certain amount of theoretical value.

>On 2015-03-05 01:29 PM, Zefram wrote:
>>Brooks Harris wrote:
>>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

No, your objective doesn't fundamentally change what the table says.

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

If your concept of a "practical timescale implementation" excludes
rubber-seconds UTC, then sure, rubber-seconds UTC doesn't arise in your
"practical timescale implementation".  That still doesn't change what
happens when one *does* consider rubber-seconds UTC.  You wishing that
it didn't exist doesn't make it go away.

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

>                                               Official TAI exists
>from the origin of 1958-01-01T00:00:00 (TAI).

That's a misunderstanding of the nature of the TAI `epoch'.  It is
not the case that TAI existed from the epoch onwards and did not exist
before.  TAI has existed to varying degrees from mid-1955 onwards, and
historically nothing special happened to it on 1958-01-01.  That date
only became special in retrospect, in late 1958.  That's when the time
scale was established in a form that we'd recognise (though not with its
present name), counting units of atomic seconds and labelling them by MJD
and equivalents.  The specialness of 1958-01-01 is merely that those MJD
labels were aligned such that TAI coincided with UT2(USNO) on that date.
TAI timestamps in early 1958 are necessarily retrospective (more so
than TAI timestamps from 1959 onwards are), and such retrospective TAI
timestamps can be applied all the way back to the start of continuous
atomic clock operations in 1955.

Are you just making an arbitrary decision that TAI from 1958 onwards is
"official" (even where retrospective) and that TAI prior to 1958 is "not
official" (even where well defined)?  If you are choosing an arbitrary
cutoff for the purposes of your project, you should be explicit about
that scope and about its arbitrariness.

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

In addition to the very dubious nature of the "need" for a specific
proleptic extension of integral-seconds UTC, you here make the jump from
*a* proleptic integral UTC to *the* time scale you are constructing.
There are many possible proleptic extensions of integral-seconds UTC,
and you have consistently failed to explain why one must specifically
use the one that has no pre-1972 leap events.

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

It would coincide exactly only in the context of your fictitious
leap-seconds-but-no-actual-leaps pre-1972 UTC.  Given the fundamental
differences between PTP and POSIX time values, having the epochs coincide
to any appreciable degree invites confusion.  Having them as close as
they are (about 8 s using real UTC, 10 s using your fictitious UTC)
is bad enough; getting them as close as 2 s (and especially the exact
coincidence with your fictitious UTC) would be asking for trouble.

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

Indeed, that's not explicit.  It's implied by the basic definition of
currentUtcOffset (as the difference between TAI and UTC) combined with
the fundamental behaviour of rubber-seconds UTC.

>                                                    In fact I see
>currentUtcOffset as being defined as integral seconds.

The protocol field is defined to only accommodate integral values,
but annex B clearly looks at the theory beyond the scope of the actual
protocol.  The integral nature of the field means that it's impossible
to handle rubber-seconds UTC by running PTP.  This will not be a problem
until a copy of IEEE 1588 falls through a wormhole into the 1960s.

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

The phrases "NTP Seconds" and "PTP Seconds" clearly refer to the scalar
values used in those protocols.  The table is directly describing a
relationship between those scalar values, and does not mention epochs
at all.

>                  If your implementation is to keep those reference
>points fixed, that tells you the constant offset.

If the epochs were both well defined, in such a way that each could be
meaningfully represented on the other protocol's time scale, then the
relationship between the scalar values would be sufficient to perform
this conversion and potentially determine a time offset between the
epochs.  But the NTP epoch is not so well defined.  The NTP epoch is
not a specific point in time, and so cannot be converted into the PTP
time scale.  It couldn't be so converted even if the PTP time scale
extended back to 1900, which it doesn't.

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

Once again, you should not use the labels "TAI" and "UTC" for such
timestamps.  Where you have invented time scales, use distinctive labels
for them.  Don't claim that they're the actual TAI and UTC.

-zefram