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

Poul-Henning Kamp phk at phk.freebsd.dk
Sat Jul 16 03:24:08 EDT 2005


In message <8366C59E-C587-4DF6-ABB0-9A9D92008DDC at noao.edu>, Rob Seaman writes:

>Nobody has invested ten cents in a  
>good luck safety net toward the retirement of leap seconds.

The entire problem is that people have not spent ten cents on
properly handling leap seconds.

>The public - including folks like applications programmers who aren't  
>educated in such issues - rely on many systems of time implicitly.   
>They rely on both interval time and time-of-day; they also happen to  
>often confuse the two.  I don't know (yet) what will break.  There  
>has simply been no work whatsoever invested in resolving this  
>question.  Most communities (including an ATC technician I talked to  
>a couple of years ago) have been left completely out of the loop.

But this is exactly the problem!

Most of these people and the systems they built don't know about
leap seconds, and therefore we will solve a lot more problems by
removing leap seconds than by trying to enforce them universally.

>As many things are likely to break because of failing to issue leap  
>seconds as are likely to break because of continuing to issue them.   

I just don't see how anything should break because of missing leap
seconds.

Leapseconds only happen in computing systems when a human somewhere
says they should happen.

The human may be an Air Force officer who spreads the news via GPS
or even the IERS employee who sends out the Bulletin C, but it is
a human in the end.

If the human doesn't say there will be a leap second, computers
won't do anything about leap seconds.

We havn't had any leap seconds for the last 6 years and I don't
recall anything apart from the leap second logic in the Motorola
Oncore GPS receivers which have broken.

That fact once again underscores that it is practically and
economically impossible to test the leap second logic in programs.

>The difference is that the former will break in ways that are harder  
>to diagnose and fix because they will represent deep seated failures  
>of the conceptual model of time.

The only way this can happen is if you use your time against an
object which is not terrestial:  Ie: you are an astronomer.

>The kinds of things that break when a leap second occur, on the other  
>hand, represent failures of engineers, programmers and managers to  
>properly implement a self-consistent conceptual model that has been  
>in place as an international standard for three decades.

100% agree.

But the most cost efficient solution is to redefine UTC, rather than
trying to reeducate people who have already ones failed to understand
the topic.

>For many purposes the concept of time can be as sloppy as you want.   

It seems to me that all we are arguing about is the name "UTC",
you want UTC to retain its current definition, we couldn't care
less.

There is nothing sloppy about that, that is just an administrative
decision.

It would make sense to fix the TAI-UTC difference at zero during
the redefinition as you propose, but that would probably give
UTC purists like yourself a nervous breakdown, and it would
mean that all clocks in the world be adjusted 34 seconds, a
pointless exercise if there ever were one.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.




More information about the time-nuts mailing list