[LEAPSECS] leap seconds schedule prior to 1972

[John Sauter]

On Wed, 2016-04-13 at 00:37 +0100, Zefram wrote:
> John Sauter wrote:
> > 
> > https://www.systemeyescomputerstore.com/proleptic_UTC.pdf.
> Your abstract says you provide a leap schedule for 1900 to 1971, but
> actually you provide a leap schedule for -1000 to 1971.  The abstract
> seems to suggest some distinction in objective between what is done
> for
> the 20th century and for the preceding 2900 years, aiming to "cover"
> the latter but "construct a table of leap seconds" for the former, a
> distinction that doesn't seem to make sense and doesn't actually
> exist
> in the paper.  (You do give the leap table in a second format for the
> 20th century portion, but in substance this is only duplicating part
> of
> the table earlier in the paper.)
> 
> Your proleptic leap schedule generally looks sane.  I haven't checked
> the numbers in detail.  It is good to incorporate Tony Finch's pUTC,
> as
> you do.  Where more than 12 leaps are required in a year, your
> extension
> to leaping on the 15th day of a month is sensible.
> 
> Your delta-T table confuses points in time with the intervals between
> them.  The delta-T column itself applies to (the start of?) the
> specific
> year listed, but the "change in delta-T" and "seconds per year"
> columns
> apply to the interval between the year listed on that line and the
> year
> listed on the following line.
> 
> The column labelling for that table, and its accompanying text, isn't
> great.  You should state what delta-T means, address units, and
> generally
> make clearer what the table means.
> 
> You write generally as if UTC exists only for 1972 onwards.  You
> should
> acknowledge the existence of the former (1961 to 1971) rubber-seconds
> UTC, and make clear that your schedule is not a proleptic extension
> of
> the whole of UTC but only of the leap-seconds form of UTC.
> 
> Your NTP material is mostly a mistake.  For NTP's purpose of clock
> synchronisation, it needs to know about contemporary leap seconds,
> but
> has no need for knowledge of historical leap seconds.  There is
> therefore
> no value, for this purpose, in extending the historical leap schedule
> further back.  It is entirely erroneous to suppose that this paper
> has
> any bearing on NTP, and I see no value in the paper mentioning NTP.
> Some of the specific things you say about NTP are in error, but I
> won't
> go into detail due to this overriding concern.
> 
> You should address the question, currently ignored, of what time
> scale
> your proleptic UTC is based on.  If your aim is to fully construct
> a time scale, this is a necessary component.  Actual UTC, both of
> the leap-seconds form and the rubber-seconds form, is defined as
> a transformation of TAI.  TAI is only defined back to some time in
> 1955, because it is defined by the actual operation of atomic clocks.
> This covers Finch's pUTC, but you go far further back, millennia
> before
> there are any atomic clocks.  The delta-T figures that you used are,
> strictly, referenced to TT.  To construct a usable time scale you'll
> need
> to use something close to TT as the basis, and manage the transition
> between your proleptic basis time scale and the real TAI-based UTC.
> I'd be inclined to use the basis TAI(TT) = TT - 32.184 s prior to
> 1977,
> switching to TAI at 1977-01-01T00:00:00 TAI when by definition
> TAI(TT)
> = TAI, though this does mean using a different basis from the real
> UTC
> for five years of real leap-seconds-UTC history.
> 
> It would be helpful for you to provide a distinctive name for the
> time
> scale that you construct.  "Proleptic UTC" is a reasonable
> description,
> but not sufficiently specific to use as a name.
> 
> -zefram
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

Thank you for your detailed criticism, Zefram.  I will think about what
you have said and revise the article.
    John Sauter (John_Sauter at systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20160412/ca346dc3/attachment.pgp>