[LEAPSECS] the big artillery

[Zefram]

Brooks Harris wrote:
>On 2014-11-04 09:04 AM, Zefram wrote:
>>POSIX is irrelevant to this,
>I don't think so. 1588/PTP references POSIX and "(POSIX) algorithms"
>many times, first in the main definition of the PTP Epoch -

The "note 1" that you quote doesn't make POSIX relevant to the definition
of the PTP epoch.  All it's pointing out is that the algorithm needed
to convert between a PTP scalar value and a broken-down TAI time is
identical to the POSIX-specified algorithm to convert between a time_t
and a broken-down UTC time.  Its wording is less than clear.

>Annex B is a long detailed explanation of how PTP was (evidently)
>designed to be compatible with POSIX.

It sounds as though Annex B may contain actual errors, in such things
as the interpretation of POSIX time_t.  Good job it's not normative.

>Well, I hope I haven't fallen into the confusion.

You appear to have mistaken your pseudo-UTC for real UTC.  You have been
confused into thinking that the rubber-seconds era of UTC somehow poses
a problem for PTP.

>Not only my conclusion, and no more ridiculous than NTP' and POSIX's
>similar use.

NTP and POSIX do not imply anything about pre-1972 relationship between
TAI and UTC.  Both of them work exclusively with UTC, and it is no
problem to them that their epochs lie in the rubber-seconds era (POSIX)
or entirely prior to the existence of TAI and UTC (NTP).  Scalar value
differences in NTP and POSIX time_t depend only on the number of UTC
days in the period in question, not on the number of leap seconds in
the period.  We've been through this before, around your CCT proposal.

>OK. I'm using the term "proleptic UTC" is the same sense NTP
>exrapolates date-time into the past.

Not the same at all.  NTP's proleptic UTC has an explicitly unknown
leap schedule, because the leap schedule makes no difference to NTP.
As a result, even though NTP explicitly refers to 1972 as the beginning
of UTC, its proleptic UTC is actually entirely compatible with the real
rubber-seconds UTC.  Your "proleptic UTC" has a specific pre-1972 leap
schedule, one which conflicts with the real pre-1972 UTC.

>I would define it thus -
>
>Proleptic UTC -

Unclear definition, as you don't address what should be the underlying
reference time scale (taking the role of TAI).  Bad name, because
"proleptic UTC" is a description for a class of time scales.  Even worse
name because your time scale isn't even in this class: it isn't proleptic
to (the whole of) UTC, it's only proleptic to *the leap-seconds era
of* UTC.  Also, as previously noted, an empty leap schedule makes a bad
proleptic extension of any part of UTC.

>On this proleptic UTC timescale, NTP picked 1900-01-01T00:00:00Z
>(proleptic UTC) as its (era 0) epoch, POSIX, 1970-01-01T00:00:00Z
>(proleptic UTC), and 15888/PTP, 1969-01-01T23:59:50Z (proleptic UTC).
>I really didn't make something new up - I just gave the idea a name.

As I noted above, the nature of the prolepsis for NTP and POSIX is
qualitatively different from the prolepsis you're using to describe the
PTP epoch as 1969-01-01T23:59:50Z.  What you're using for PTP there isn't
something taken from NTP or POSIX.  I don't know whether you invented it;
you're certainly not the *only* person to have invented it.  As for naming
it, in <mid:5453C968.9050400 at edlmax.com> you referred to it using only the
ISO 8601 "Z", implying UTC, and in <mid:5457C54D.6010308 at edlmax.com> you
explicitly referred to it as "UTC".  Only when pushed have you admitted
that it's not actually UTC.  You seem to think that it's somehow a
uniquely correct proleptic extension of the leap-seconds era of UTC,
which is far from the case.

>>   This happens because (as with the
>>CCT proposal) you've supposed that there are no leap seconds in the
>>proleptic era.
>Correct. Same as NTP and POSIX.

As noted above, NTP and POSIX do not imply any specific proleptic
leap schedule.  Back in <mid:20140118110620.GM21945 at fysh.org> in the
CCT thread I asked where you got the idea that NTP implies no leaps
pre-1972, and you didn't answer.  As best I can tell, you've looked at
the scalar value differences, treated them as pure counts of TAI seconds,
and concluded that they imply no leaps.  But that logic would lead you
to conclude that UTC *never* leaps.  NTP scalar values and POSIX time_t
values are not pure counts of seconds, but are defined to count 86400
per UTC day regardless of leaps.

>>So, in summary, your pseudo-UTC is pointless, misrepresented, and
>>defective.
>I hope you'll reconsider that.

My opinion stands.  Your parallels with NTP and POSIX are erroneous,
and your pseudo-UTC would still have the same faults even if it were
also used by such other standards.

>being used by some in the 1588/PTP community. Any suggestions as to
>better clarify it accepted.

I'd be happy to fully critique IEEE 1588, if someone were to provide me
with a copy.

-zefram