[LEAPSECS] Negative TAI-UTC

[Brooks Harris]

On 2017-02-04 03:27 PM, Warner Losh wrote:
> 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.

I agree. I don't think any significant change to the UTC specs can or 
will occur because of reverse compatibility for too many users and 
applications. Killing Leap Seconds, adopting a different schedule of 
introduction, or changing the DUT1 tolerance are all significant 
changes. I asked the question, but the I think answer is we must cope 
with it. And we can. I think the only fix the specs need is *clarity* - 
there's too much room for interpretation.
-Brooks