[LEAPSECS] Negative TAI-UTC

[Warner Losh]

On Sat, Feb 4, 2017 at 11:12 AM, Brooks Harris <brooks at edlmax.com> wrote:
> On 2017-02-04 12:24 PM, Warner Losh wrote:
>>
>> On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather <clive at davros.org>
>> wrote:
>>>
>>> Looking only into the future, not historical data, what do people think
>>> the
>>> probability is that TAI-UTC will ever be negative? Should data structures
>>> be designed to handle this case or not bother?
>>
>> Doubtful, but not impossible.
>>
>> LoD would have to increase significantly for that to happen. The
>> current LoD delta is about 1ms. This looks to vary between -500us to
>> 2ms on IERS' web page (http://hpiers.obspm.fr/eop-pc/index.php).  It
>> also looks like the short term forecast is to return towards 0 in the
>> next 150 days or so. Looking at even longer term data from
>> http://www.usno.navy.mil/USNO/earth-orientation/eo-products/long-term
>> we see huge error bars for LoD just a few hundred years ago and a big
>> drop in deltaT from 1850-1900. So the data we have suggests that it is
>> unlikely, but not outside the realm of possibility.
>>
>> It's quite likely that the first negative leap second would have a
>> much higher bug rate than the current positive leap code which has at
>> least been tested several times and is known to still have issues.
>
> Yes, a negative Leap Second seems especially dangerous to me. How many
> devices and applications have been exhaustively tested for that condition?
> I'd think the IERS should be especially nervous about issuing a negative
> Leap Second. The smears would have to go the other way too.

That's my prediction too. I know that at least some of the code I was
involved with has experienced a negative leap second since we had to
show the contracting office that we could handle a negative leap
second end to end by running our gear in a GPS simulator that lied to
the GPS receiver and told it there was a negative leap second coming.
But I do recall fixing a bunch of bugs to make this possible (by
simulating the GPS putative output and driving the rest of the
software from that). More bugs than I had to fix for positive leap
second testing before 2006...

> What if the negative Leap Second possibility was eliminated from the
> specification so only positive Leap Seconds were allowed? If the DUT1-to-UTC
> <.9s were relaxed, how far from DUT1 might it go? Would it matter, how much,
> and to whom?
>
> That would have a rather significant impact on simplification of
> implementations, eliminating one whole set of cases and test conditions,
> wouldn't it? That could lead to more reliable and uniform behavior, couldn't
> it?

I'd say there'd be some objections from people that need UTC to be
within the arbitrary second of DUT1 since their applications assumed
this to be the case and cannot be adjusted somehow. When I started on
this list, I'd say the list is small, but unknown. After years of
doing this, we know there's some telescopes that cost big bucks to
make, but have proprietary software that assumes UTC == UT1 for
initial coarse aiming and the errors in aiming get too large if that
number grows north of a second. There's also talk of sky facing
applications for near earth objects that need this too, but they also
need the IERS rapid forecast group to give them numbers to within a
millisecond. Plus there's an unknown amount of software that checks to
make sure it is < 0.9s (or maybe 1.0s) or that's in old-school FORTRAN
fixed column format that can't overflow. Plus we don't know how large
a negative offset would be, which would make a lot of people nervous.

If we're looking to relax the magnitude of DUT1, perhaps it would also
be time to make the adjustment algorithmically rather than
observationally? That is, lay out a schedule for N years that's
regular as clock work and adjusted on the 'back end' every few years
if the earth is turning significantly faster or slower than the
prediction... However, I'm not so sure that even this small step is
possible.

Warner