[LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Thu, 2016-04-21 at 18:49 -0700, Tom Van Baak wrote:
> > 
> > Hi Tom,
> > 
> > The values presented in the 2004 Morrison and Stephenson paper are
> > already smoothed using a series of cubic splines and a parabola
> > prior
> > to -700.  See their table 1 and its discussion.  The authors
> > recommended simple interpolation between the listed years, so I did
> > that rather than add additional smoothing.
> Right. Just use their polynomial then, or go back to their original
> data.
> 

Based on your suggestion, I found an earlier paper, at 

<http://www.caeno.org/_Feat/pdf/F53_Stephenson_Delta-T%20complex%20anal
ysis.pdf>.

However, I doubt that going back to their original data, and repeating
their analysis, will result in a simpler form of the table, with as
much accuracy.  Consider that they "patched" their table in the 2005
paper--a simpler form would have to include that.

> > 
> > To me, the only troubling thing about creating a high-precision
> > representation of low-precision data is the implication that the
> > result
> > has greater accuracy than its source.  I attempted to address that
> > in
> > my conclusion by stating that the choice of extraordinary days in
> > ancient times is somewhat arbitrary.
> With pUTC you're already throwing away 90% of what UTC stands for.
> The only thing you retain is applying a leap second just before
> midnight. So instead of pages of prose that describe how to do the
> mapping, with every century or decade different, why not just
> generate a function that converts JD into a proleptic leap second
> count. Since pUTC is fictitious anyway, there's no requirement to
> have the leaps at the end of a month or weirdly spaced on the 15th or
> 28th/29th/30th/31st. Instead just generate a leap on the day when
> it's needed, regardless of what day number or month number it is.
> 
> I say this because you're generating a subjective table, one based on
> data from a fitted polynomial, which is itself based on measurements
> of dubious accuracy in the first place, measurements that can be
> revised from time to time depending on historical research. The whole
> thing doesn't pass my smell test.
> 
> The other way to think about it, what are you minimizing or
> maximizing in the design of your tables. If someone else comes up
> with a different table design, how do you choose which is better. Is
> minimum RMS of |DUT1| the goal? Must |DUT1| < 0.9 s? How can you be
> sure? Can you have double leaps instead of single leaps twice a
> month? Must the leaps occur only at the end of a month? Why not space
> them every 365 / N days within a year? Then again, at this level
> you're dealing with JD anyway, so pUTC doesn't itself need to be tied
> to years, or arbitrary power of ten boundaries. Morrison and
> Stephenson's use of year isn't exactly strict.
> 
> Think about the code that some poor programmer is going to have to
> write as they read your PDF. Instead of an if-else-if sequence that
> goes on for pages, is there a simpler way to generate pUTC? I mean,
> no human is going to read your PDF and manually go through the
> guidelines you present. So maybe think of the code first instead of
> the prose.
> 
> It looks to me like you have a subjective solution looking for a
> poster child problem. I would feel much better if you or anyone else
> on the list could start with a couple of real examples of a problem,
> and then consider what algorithmic solutions solve the problem.
> 
> /tvb

My goal in the paper is to extend the modern definition of UTC back in
time.  Hence, I use the rules of UTC whenever possible.  Thus,
extraordinary days are the last day of the month, and are limited to
86,399 or 86,401 seconds.  Considering that Morrison and Stephenson did
the heavy lifting in determining delta T, I wished to defer to them.

To address the coding problem, I have been thinking that I should
create a table of extraordinary days and publish it.  That would make a
good follow-up to the paper, in my opinion.

Yes, this is a solution looking for a problem.  Perhaps there is a
problem out there looking for a solution, and by publishing this paper
I can bring the two together.
    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/20160422/bbfab4f3/attachment.pgp>