# [time-nuts] Re: UTC - A Cautionary Tale

M. Warner Losh imp at bsdimp.com
Sat Jul 16 21:00:51 EDT 2005

```In message: <000201c58a67\$a2401360\$0500a8c0 at darius.domain.actdsltmp>
"Bill Hawkins" <bill at iaxs.net> writes:
: My little program served the needs of civil time. It backs up
: at 59 seconds because the display software can't handle 60.
: That seems close enough for civil work. If you must have
: monotonically increasing time then it is a mistake to use
: civil time. You want TAI because you are not concerned with
: time of day.

But the UTC standard mandates displaying 60 for the a positive
leapsecond.  Your program failed to implement the standard.  Other
program expect to have standard conforming time sequences.  The stupid
details matter and are important.  Getting them right is hard because
of the amount of research into the problem involved, the amount of
time one has to spend testing all the weird edge cases, and the amount
of time one has to spend proving to oversight boards that you did it
right.

There are also problems with just using TAI, as has been outlined
several times.  Time sources are in UTC, and you need a leapsecond
count to recover TAI.  Alternatively, you can push the problem into
the time display code, but that means that 'naive math' to calculate a
time is no longer possible and you have to have a table of all leap
seconds to do the job properly.  No matter which way you fall on this
issue, you have problems that bite you when you least expect it.  Your
attempt to show us all how 'easy' it is ran afoul of these problems
and rather proved our point.

: As to not handling the leap second interval as 59, 60, 0,
: what do you do when the Earth speeds up and it goes 59, 1?
: If the variations are due to the mantle floating on the core,
: there probably will come a time when it speeds up.

You're not following the standard again.  If the leap second is
negative, the sequence is 57, 58, 0, 1.  Again, it is all covered in
the standard.  Negative leap seconds, though extremely unlikely, are
part of the specification, and also need to be tested.  The sequence
of time matters, and there is hardware that will fail if upstream time
providers do it wrong.

: As to manually setting a leap second switch with only 6 month's
: notice, I don't understand your problem. I'd rather have a one
: month notice so it didn't get postponed until the notice was
: forgotten. I believe Mills' NTP has a leap second flag that
: automates that part of the process.

Yes and no.  NTP only turns on the leap second flag on the last day of
the year to say 'there will be a leap second today.'  So while it
automates much of this (and is the signal that the kernel uses to
implement the leap second), it doesn't act as a good way to warn
people that one is coming.  That has to come through other channels.
So while the computers are likely to get it right on the day of the
event, if you've not made plans to ensure that other parts of your
operation are covered, you'd be in for a surprise.

I should also explain that I personally tested FreeBSD and ntp's
response to a leap second.  I've fixed bugs that were introduced
shortly after the last leap second that had gone unnoticed for 4 years
until I tested them.  I've tested both the positive and negative leap
second scenarios.  I've found bugs in the kernel portion of ntpd as
well.  This stuff is hard to get right, even for experts like Dave
Mills.

Warner

```