[LEAPSECS] Bulletin C and all that

[Zefram]

Brooks Harris wrote:
>Meantime, the epochs of NTP and POSIX are defined in terms of "UTC",
>but before 1972-01-01T00:00:00Z (UTC). They exist on a timescale I've
>been flamed for calling "proleptic UTC". This a timescale that
>extrapolates the Gregorian calendar counting method *uncompensated
>for Leap Seconds or anything else* into the (indefinite?) past before
>1972-01-01T00:00:00Z (UTC).

You have repeatedly made statements along these lines, but despite clear
disagreement you have yet to justify this position.  By "uncompensated
for leap seconds" you apparently mean "not including leap seconds";
you are proposing a proleptic pseudo-UTC with an empty leap schedule.
It appears to me that the definitions of NTP and POSIX time, and Annex
B of IEEE 1588 which you've previously linked to this issue, are all
silent on the leap schedule for pre-1972 UTC.  Please explain how these
documents all lead you to perceive a specifically empty leap schedule
for pre-1972 pseudo-UTC.

For example, in <mid:53FDE296.9070901 at edlmax.com> on 2014-08-27 you
quoted the definition of NTP, RFC 5905:

# In the date and timestamp formats, the prime epoch, or base date of
# era 0, is 0 h 1 January 1900 UTC, when all bits are zero.  It should
# be noted that strictly speaking, UTC did not exist prior to 1 January
# 1972, but it is convenient to assume it has existed for all eternity,
# even if all knowledge of historic leap seconds has been lost.

and then in the immediately following paragraph you wrote:

|This describes a proleptic UTC timescale that is *uncompensated for
|Leap Seconds*, that is, it extrapolates the Gregorian calendar
|counting method into the past from 1972-01-01T00:00:00Z (UTC).

I am at a loss to see how a standard that explicitly describes the leap
schedule (of its explicitly fictitious pre-1972 UTC) as unknown leads you
to say that it is describing a known empty leap schedule.  This requires
explanation on your part.  How do you make this extraordinary leap
of logic?

Later, in <mid:5457C54D.6010308 at edlmax.com> on 2014-11-03, you said
that table B.1 in IEEE 1588 (PTP), which describes relationships
between various time scales, contradicts the use of rubber-seconds UTC.
Elsewhere in the same message you said

|          The conclusion is that the PTP Epoch is 1970-01-01T00:00:00
|(TAI) which *must be treated as* 1969-12-31T23:59:50Z (UTC), *not*
|"1969 23:59:51.999918 UTC" as stated in the 1588/PTP document. The
|reason is to maintain an integral-second alignment between the PTP
|Timescale and the UTC timescale.

which uses motivation of rejecting rubber seconds to reach a conclusion
of TAI-UTC at 1969-12-31 being not just integral but specifically exactly
10 s.  You thus imply again a known empty leap schedule rather than an
unknown leap schedule, let alone a known rubber schedule.  But between
the motivation and the conclusion you omitted to include any reasoning.
How does IEEE 1588 lead you to perceive an empty 1969-to-1972 leap
schedule?

Later in the same thread I reviewed the actual text of IEEE 1588's Annex
B, and found that the table of conversions is silent on pre-1972 UTC.
You found this confusing, and so in <mid:20141105101706.GF31133 at fysh.org>
I explained at great length how the conversion formulae don't supply
a leap schedule but operate on whatever leap schedule the user cares
to plug into them.  I omitted on that occasion to turn the question
round, but this seems a good point to do so: how do you find that
table B.1 implies a specific leap schedule (pre-1972 or otherwise)?
You wrote a bit about the origins of PTP and NTP being pre-1972, but
that's irrelevant because the conversions don't operate on the origins
(or anything else) as actual points in time.

>                                   (By the way, why is there no
>accepted term for the idea of calendar date and time-of-day together,
>I wonder?)

I've used the term "calendar time".  I guess that the lack of a common
term is down to the two aspects of timekeeping having been developed
fairly separately, and only recently (past couple of centuries) being
frequently required to work together.

>           This because TAI is often also represented as a date-time
>but there is rarely a clear distinction made about what it means.

I find it perfectly clear.  TAI ticks seconds that attempt to realise the
SI second on the rotating geoid, and regular groups of 86400 consecutive
seconds are bundled together and labelled as a day.  The days themselves
are labelled by means of MJDN or the calendar of one's choice, as if
they were the solar days for which these labelling conventions were
originally developed, but the link between the solar days and the TAI
days is little more than notional.

>ITU-R  TF.460-6 says -
>B    International atomic time (TAI)
>"... from the origin 1 January 1958 (adopted by the CGPM 1971)."
>
>What, do you suppose, does "1 January 1958" actually mean?

It refers to the establishment of what we now call TAI, by means of a
retrospective synchronisation such that 1958-01-01T00:00:00 TAI occurred
at 1958-01-01T00:00:00 UT2(USNO), as best this could be determined at
the time this was performed (late 1958).  In the context of that clause,
"1 January 1958" seems to refer specifically to that point on the TAI
time scale: it's talking about counting the notional days, hours, minutes,
and seconds *of TAI*.

>                                                           I guess it
>can't be on some "proleptic UTC" timescale because UTC doesn't yet
>exist, so it must be on an uncompensated Gregorian calendar
>timescale, I think.

To the extent that it's referring to any time scale other than TAI, that
time scale is UT2(USNO), or more loosely UT2 or vague UT.  These time
scales indeed don't have leap seconds, but their seconds are wildly
rubbery.

>So, how many (integral) seconds between 1958-01-01T00:00:00 (TAI) and
>1972-01-01T00:00:00 (TAI)?
>
>1972-1958 = 14 years * 365 = 5110 days + 3 leap year days = 5113 days
>* 86400 seconds = 441763200 seconds.

Correct, with the proviso that this is specifically counting the seconds
of TAI.  The number of seconds of UT2, or in general any other time scale,
would be different.

>So now the tricky question - how many (integral) seconds between
>1958-01-01T00:00:00 (TAI) and 1972-01-01T00:00:00Z (UTC)?

Not at all tricky.  That UTC time corresponds to a well-defined TAI
time of 1972-01-01T00:00:10, and you ultimately come up with the correct
answer of 441763210 seconds (again, TAI seconds).

>http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat says -
>
>#    MJD        Date        TAI-UTC (s)
>#           day month year
>#    ---    --------------   ------
>#
>    41317.0    1  1 1972       10
>
>What, exactly, does this mean? Do we interpret the MJD value as
>uncompensated Gregorian calendar, or should the conversion include
>the 10 second initial offset somehow? What does "1  1 1972" mean,
>exactly? 1972-01-01T00:00:00 (TAI) or 1972-01-01T00:00:00Z (UTC)?

The date, given in both Gregorian and MJD forms, refers to the
days of UTC.  The TAI-UTC difference of 10 s came into effect at
1972-01-01T00:00:00 UTC.

>                   Put another way, is the "UTC epoch"
>1971-12-30T23:59:50 (TAI) = 1972-01-01T00:00:00Z (UTC)?

I don't see how you could possibly reach this conclusion.  This would
involve TAI-UTC being -10 s, which is clearly not justified by the
table entry.

>                                                        Or should it
>be represented as 1972-01-01T00:00:00 (TAI) = 1972-01-01T00:00:00Z
>(UTC)?

This too is silly, involving TAI-UTC = 0 s.

If one were to interpret the date in the table as referring to
the beginning of a TAI day, then one would come up with an epoch of
1972-01-01T00:00:00 TAI = 1971-12-31T23:59:50 UTC.  That interpretation
of the table would mean that leap seconds occur a few seconds before
midnight, in the middle of a UTC minute, which would leave no unambiguous
notation for them (23:59:60).  So although the table isn't explicit
about the dates being UTC, the knowledge that leap seconds occur at the
end of a UTC day clarifies the matter.

>I've seen many implementations that do not agree by 10 or 20 seconds,
>indicating I'm not the only confused reader.

I expect that a 10 s disagreement would arise from a leapless TAI-like
time scale synchronised to UTC at 1972-01-01.  That time scale amounts to
TAI - 10 s, so mistaking it for TAI would lead to a constant 10 s error.
The Olson `right' tzfiles are effectively based on using this time scale
in the guise of time_t, so I wouldn't be too surprised at seeing it in
the wild.

I don't see where you'd get a 20 s disagreement from, but maybe you've
seen a 19 s disagreement, which (ignoring nanosecond clock differences)
is the constant difference between TAI and GPS time.  GPS time was
synchronised to UTC in 1980.

-zefram