[LEAPSECS] My FOSDEM slides

[Brooks Harris]

On 2015-03-08 12:45 PM, Zefram wrote:
> 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.
OK, yes, we're thinking of it differently, I guess, or at least I may 
have misrepreented your meaning in my pose. But as you explain it here 
thats what I'm thinking too. Any given value of time_t or an NTP time 
value has "lost all knowledge of Leap Seconds" and so has slipped its 
epoch with each Leap Second, in effect creating multiple timescales.

I must admit I didn't understand the significance of this subtly for a 
while -

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

I'd read that many times before it sunk in. Oh! The epochs are actually 
shifting! And so there are multiple timescales! Wow! Now I get it!

This is what I understood your use of "scalar" to be referring to.

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

I agree, "a certain amount of theoretical value", and, indeed, a fairly 
large amount of practical timekeeping capability. If implemented 
correctly, NTP and POSIX accurately represent date and time-of-day 
*except* on the Leap Seconds themselves. But, of course time_t's epoch 
is slipping about with respect to post 1972 UTC.

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

I didn't say it changed the table in some way. I said I'm using those 
values to calculate the offset between NTP prime epoch of era 0 and 1972 
UTC. I'm then using that as a *fixed* epoch of my timescale.

>
>>>                              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".
Right. Same as NTP and POSIX - they don't represent accurate date-time 
before 1972.

> That still doesn't change what
> happens when one *does* consider rubber-seconds UTC.
Yes, you need to switch to an alternate timescale. There *is* an implied 
timescale with non-integral measures from 1961 to 1972 that doesn't have 
a name. That's what you need in that period if that's your purpose. In 
*my* timescale, and NTP and POSIX, this period lies in the "inaccurate 
proleptic integral seconds period before 1972".

> You wishing that
> it didn't exist doesn't make it go away.
I didn't make it go away. I ignore it for purposes of timekeeping after 
1972, replacing it with a "proleptic extrapolation of seconds prior to 
1972 for convenience of calculation" the same way NTP and POSIX do. 
time_t doesn't know anything about the rubber-band era in lies within.

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

>
>>                                                Official TAI exists
> >from the origin of 1958-01-01T00:00:00 (TAI).
>
> That's a misunderstanding of the nature of the TAI `epoch'.
Not a misunderstanding, I don't think. A "recasting" of its use, perhaps.

>   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.
Right. But like the "rubber-band era" they are beside the point of 
timekeeping after 1972, and you could construct a scale for that period 
for that purpose.

>
> 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)?
The only time point I consider "uncontroversially official" is 
1972-01-01T00:00:00Z (UTC) = 1972-01-01 00:00:10 (TAI). The NTP spec is 
quite explicit in RFC 5905, Figure 4: Interesting Historic NTP Dates. 
The POSIX "the Epoch" spec is *intentionally* vague. 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). As commonly used, most 
modern systems operate at integral seconds, and most seem to align to 
NTP's figure Figure 4: Interesting Historic NTP Dates.

>    If you are choosing an arbitrary
> cutoff for the purposes of your project, you should be explicit about
> that scope and about its arbitrariness.

Yes. Its objective is accurate UTC after 1972-01-01 00:00:10 (TAI) = 
1972-01-01T00:00:00Z (UTC) while accommodating the commonly used primary 
proleptic epochs of several important timekeeping systems, NTP, PTP, and 
POSIX.

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

It hinges of NTP's specification, including NTP's figure Figure 4: 
Interesting Historic NTP Dates.

The NTP "prime epoch of era 0" *includes* the initial ten-second TAI-UTC 
offset imposed at 1972. There is a 10 second offset from the NTP prime 
epoch until the first actual Leap Second on 1972-06-30T23:59:60 -> 
1972-07-01T00:00:00.

(By the way, there is no generally accepted term for this initial 
ten-second TAI-UTC offset I'm aware of. They are often lumped in as 
"Leap Seconds", but that's not quite right.)

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.

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

Ah, no. The PTP timekeeping community wisely ignores all the 
shenanigan's about "the rubber-band era" explained in the PTP spec 
because its too complex and not required for UTC after 1972.
>
>> 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.
Exactly. So, who cares? And why all the fuss about it? OK, maybe, maybe, 
the "theory" as explained in it is correct (I don't think so, but..) but 
it just doesn't matter.

> This will not be a problem
> until a copy of IEEE 1588 falls through a wormhole into the 1960s.
Yes, so, why are we going on about it? If you need to account for the 
"rubber-band era" or any other date-time before 1972 you've got to 
switch to some other timescale for the purpose.
>
>> "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.
True. But they define the relation between epochs if you interpret them 
that way, which is what I'm doing to place each epoch at a fixed offset 
proleptic to 1972.

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

> 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" and is 2272060800 seconds before the "First day UTC".
> 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.
Sure you can *if* you extrapolate propleptic TAI back to 1900 (or 
conceptually, to the indefinite past).

>
>> 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.
I agree, its a bit careless, but I need a name for them you or somebody 
might accept. I'm still cogitating on that.

-Brooks

>
> -zefram
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>