NavList:

   

Reply

On 2016-07-09 17:38, Lu Abel wrote:
> Normally, UTC goes (at midnight)23:59:5823:59:5900:00:00
> Note there is no 23:59:60 because the 60-second count goes from 00 to 59
> With a leap second, it goes23:59:5823:59:5923:59:60  (this is the leap second)00:00:00

Lu is the first to hit the nail on the head. It's almost 36 hours since
I posted that same paragraph to the LEAPSECS list, of all places, and
nobody there has said anything about the goof yet!

Contrary to the USNO's press release, nothing special happens at
23:59:59. As Lu said, the leap second begins at 23:59:60.

I think the usual description in terms of consecutive whole seconds is
not optimum, however. I prefer half second steps:

23:59:59.5
23:59:60.0
23:59:60.5
00:00:00.0

That makes clear the notation at the boundaries and inside the leap
second. Many programmers don't seem to realize there is a notation for
events inside a leap second. The JPL HORIZONS online ephemeris, for
instance, returns an error message if you request the coordinates of a
body during a leap second. Is that nitpicking? Not if you rely on
HORIZONS as a gold standard to test your own software! That's how I
discovered the bug. (The workaround is to convert UTC to TT, which
HORIZONS accepts without difficulty.)

I'm not sure if this flawed UTC implementation was a product of
ignorance, oversight, or a decision to take a shortcut. A JPL analyst
agreed it needs fixing, but warned nothing was going to happen anytime
soon. He was right. That was in April 2014, and the bug is still there.

   

Reply