On Tue, 31 Jan 2017, Tim Shepard wrote:
Richard Clark <rcl...@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
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
