[LEAPSECS] BBC radio Crowd Science

[John Sauter]

On Sun, 2017-01-29 at 10:28 -0800, Tom Van Baak wrote:
> > but I've always thought the
> > instant of the change was unambiguous, and that it was
> > instantaneous in both cases.
> 
> Correct.
> 
> > I've only shown half-second increments, but in the limit, in the
> > positive case, TAI-UTC would be precisely 35 for every instant of
> > the second numbered 60, and changes to 36 at the first instant of
> > 00:00:00 UTC.  Similarly, in the negative case, it's 35 for all
> > of 23:59:58, and again changes at the first instant of 00:00:00.
> 
> Correct. And the fraction- or half-second technique is useful to
> illustrate this.
> 
> > (For me this
> > helps explain the oddity that leap second tables typically list
> > the days *after* what feels like the leap second days: the tables
> > list the first instant of each new TAI-UTC value, which ends up
> > being the instant after the "essential discontinuity".)
> 
> Yes, I've thought the same.
> 
> There is a wide variety of leap second table formats; in print, on
> the web, and in code. A good number encode the end of the month date
> (e.g., 6/30) and a good number encode the beginning of the month date
> (e.g., 7/1). At one level it doesn't really matter. But there are
> often subtle user-interface or programming or testing reason to
> choose one over the other. I used to have strong preferences, but now
> I more appreciate the extent of programmer creativity.
> 
> Lookup tables that just deal with UTC leap seconds tend to use the
> 6/30 format. Tables that work with TAI and UTC or TAI-UTC tend to use
> the 7/1 format. Tables that were designed with positive leap seconds
> on the brain are more likely to use the 6/30 format.
> 
> Given when leap seconds happen local time, those of US in the far
> west tend to think of leap seconds happening in 6/30 format while
> those from Paris to the far east tend to think of leap seconds
> happening in 7/1 format. Index-1 programmers (e.g., FORTRAN) may
> unconsciously use <=, or 6/30 format, while index-0 programmers (C)
> may think of <, or 7/1 format.
> 
> Some tables encode if the leap is +1 or if the leap is -1. Some
> encode the length of the minute (59, 61). Some encode the length of
> the day (86399, 86400, 86401). Some tables use year and month only,
> some use year, month and day (redundant), some use MJD, some use JD,
> some use unix time_t, some use NTP time, some use GPS time.
> 
> So there's a wide variety of formats. I'm working on a "best
> practices" document with a pile of examples of how it's done, and how
> to do it right. Also, lots of embarrassing examples from the web of
> how it's done wrong.
> 
> /tvb

I look forward to seeing that document.  I hope that among the many
examples of tables you have collected you included two that I have done
recently.  One codes days as JD, using the 7/1 convention, and codes
the leap information as the value of TAI-UTC.  The other also codes the
days as JD, but uses the 6/30 convention, and codes the leap
information as the length of the day.

I am located in the US and have programmed in FORTRAN.  Algol was my
first language but it also uses index-1 arrays.

If you project far enough into the past or future, leap seconds are not
always on the last day of the month, so for those applications the day
is not redundant.
    John Sauter (John_Sauter at systemeyescomputerstore.com)