[LEAPSECS] BBC radio Crowd Science

[Richard Clark]

On Tue, 31 Jan 2017, Tim Shepard wrote:
>
> Richard Clark <rclark at noao.edu> wrote,
>
>> immediately comes to mind then it will have no difficulty handling
>> the non-normalized 23:59:60 and putting it 86401 seconds after
>> 00:00:00 earlier that day. So here you can apply the new value of
>> (TAI-UTC) starting with the first second after the leap second.
>
>
> It seems to me that 23:59:60 is 86400 seconds after 00:00:00 earlier
> that day (on a day which will end with a leap second).  Not 86401
> seconds as you said.
>
> It is 00:00:00 of the next day (after a leap second) that would be
> 86401 seconds after 00:00:00 (of the day before the leap second).

oops.
Yes, you are right.
But it comes out to the right number that the use of the new value of
(TAI-UTC) is deferred until after the leap second. That is, 00:00:00
of the first day of the new month.

Also, on reflection, I don't think there would be the need for frantic
fixes in the event of a negative leap second.

> I'm assuming that the timestamps you wrote refer uniformly to the
> beginning of the second they label.

Yes, an integer valued second is N.0000

> 23:59:60.000 is 86400.000 seconds after 00:00:00.000 , and
> corresponds to the beginning of the leap second.
>
> 23.59.60.999 is 86400.999 seconds after 00:00:00.000, and corresponds
> to almost the end of the leap second, and is *almost* 86401 seconds
> after the 00:00:00.000 earlier that day.
>
>
>
> To me, Warner's recent posts have been helpful in understanding what
> is going on during the leap second.  (There may be multiple correct
> ways of thinking about what happens during a leap second, but some
> (like Warner's) seem better (more straightforward) than others.)

It has been a very useful discussion.
Formally, a given value of (TAI-UTC) is applicable within the interval
  [yyyy-mm-ddT23:59:60 until yyyy_end-mm_end-dd_endT23:59:60)

Any aproach using quick and dirty arithmetic should properly emulate this.

Richard