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

Bill Hawkins bill at iaxs.net
Sat Jul 16 20:36:55 EDT 2005


Oh, dear. I have made a mistake. I had not realized that
I was dealing with purists who love to argue.

Here are my understandings of the time scales:

UTC: Civil time, what most people mean by time of day. Was
determined by star crossings at Greenwich, now related to
TAI in that both use the same oscillator frequency.

Leap second: An adjustment made to UTC to keep it civil.
The Earth slows down at an unpredictable rate. In the
current history of UTC, the Earth has never speeded up
or needed a change other than at July or September.

UT1: Astronomers time, also related to TAI by frequency
but adjusted more closely by star crossings.

TAI: Atomic time, maintained by counting atomic oscillations
averaged over many atomic clocks. Monotonically increasing.

UT was born in 1928. There are several numbered versions.

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.

In fact, civil time is corrected by seconds because civilians
don't measure time closer than a human reaction time.

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.

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.

Could it be that most computers don't have leap second code
because they get their time with NTP? It's pretty civil.

I'll grant you that you can write thousands of lines of code
to get a GUI to do something right.

My field is industrial process control. It is important that
timestamps on alarms and events be monotonically increasing.
Before MS took over the computing systems, I worked with one
that had a rate adjustment, like a mechanical clock. Range
was +/- 128 seconds per year. You had to report to the Plant
Manager to be authorized to set anything but the rate. Most
users didn't use savings time because a one hour overlap is
too confusing when your alarm list is sorted by timestamp.

Regards,
Bill Hawkins

...as we approach 100 messages on this subject since 4 July.





More information about the time-nuts mailing list