[Poul-Henning Kamp: UTC questionnaire]

Garrett Wollman wollman at khavrinen.lcs.mit.edu
Thu Dec 2 21:22:51 UTC 1999


For your edification....  (Forwarded by permission.)

-GAWollman

------- start of forwarded message (RFC 934 encapsulation) -------
Message-ID: <2538.944162601 at critter.freebsd.dk>
From: Poul-Henning Kamp <phk at critter.freebsd.dk>
To: dnm at orion.usno.navy.mil
Cc: core at freebsd.org
Subject: UTC questionnaire
Date: Thu, 02 Dec 1999 20:23:21 +0100


Dear Mr. Matsakis,

I am answering your questionaier on behalf of The FreeBSD project,
a supplier of a UNIX family Computer Operating System:

>A. If the appropriate international bodies decide to eliminate the
>insertion of new leap seconds, would you foresee any practical 
>problems for your institution/instrument/observations?
> 
>  *  no  ____

In fact it would eliminate a few minor inconveniences every time
it happens:  UNIX computers account for time using the UTC scale
with an epoch of 00:00 01/01/1970 UTC, so the computer needs its
clock adjusted for a leap-second.

Online transactions is a phenomena in sharp increase and the issue
of keeping and legally documenting "time of transaction" in the
face of leap-seconds is certainly too expensive for the benefit we
see from them.

UNIX is also a widely used operating system for science and research
and the fact that no widely available facilities exist for calculating
actual time difference between two events on either side of a
leap-second is known to have bitten more than one scientific author
over the years.  Obviously it would be simple to provide these
facilities, but the fact that operating systems are seldomly upgraded
would relatively soon render the list of leap-seconds obsolete and
the facility thereby useless.

>B. Would you be in favor of such a proposal?
> 
>     yes ____
> 

Absolutely.

If it is deemed desirable to keep UTC and UT1 synchronized it would
be of tremendous benefit if the leap-seconds could be predicted or
even just declared earlier than in the current mode of operation.

A rule along the lines of "a leapsecond every 18 months" would go
a long way to keep UTC and UT1 tied closely while at the same time
providing a predictability for "normal civilization" equivalent
to what we know from leap-days.

Alternatively, rather than abandon leap-seconds make it leap-minutes.
Once in a century we could probably use an extra minute anyway.

Poul-Henning Kamp
phk at FreeBSD.org

In message <199912021444.PAA09602 at hpopa.obspm.fr>, iers at hpopa.obspm.fr writes:
>
>***************************************************************************
>	Gazette IERS Gazette IERS Gazette IERS Gazette IERS Gazette 
>                                   ________________________________________
>	No 48, 02 December 1999   /
>_________________________________/        Contact: iers at obspm.fr
>                                     ftp: hpiers.obspm.fr (145.238.100.28)
>                                     WWW: http://hpiers.obspm.fr
>***************************************************************************
>
>        Subject: UTC Questionnaire 
>        Author : Demetrios Matsakis 
>
>--------------------------------------------------------------------------
>
>
>Dear Colleague,
>
>It has been proposed to change the definition of Coordinated Universal
>Time (UTC) regarding the insertion of leap-seconds, possibly even
>eliminating their use.  Leap seconds are introduced so as to keep UTC
>synchronized (within 0.9 s) to the time scale determined from the
>Earth's rotation.
> 
>Should no new leap seconds be inserted, solar time will diverge from
>atomic time at the rate of about 2 seconds every 3 years, and after
>about a century |UT1-UTC| would exceed 1 minute.  Although no
>fundamental problems are anticipated, it is very likely that Y2K-like
>problems may result in software that assumes UT1=UTC, or 
>|UT1-UTC|< some value, or whose input/output records use a field size
>that can only accommodate |UT1-UTC| values up to one second.
> 
>To gather information, an URSI Commission J Working Group was formed,
>consisting of Don Backer, Wim. N. Brouw, Barry Clark, Irwin Shapiro,
>Ir. E. Van Lil, and myself.
> 
>We would like to ask you to consult with the members of your institute
>who currently deal with UT1-UTC, and give us a considered response to
>the following two questions:
> 
>A. If the appropriate international bodies decide to eliminate the
>insertion of new leap seconds, would you foresee any practical 
>problems for your institution/instrument/observations?
> 
>     yes ___
> 
>  *  no  ____
> 
>  *  possibly ____
> 
>     (* please explain any known or possible problems)
> 
>B. Would you be in favor of such a proposal?
> 
>     yes ____
> 
>     no  ____
> 
>     indifferent ___
>
>     have better idea ___
> 
>     (feel free to comment)
>
>C. Is there anyone else you would recommend we contact?
>    (feel free to forward this eamil directly)
> 
>I would appreciate your assistance, and a response by January 15 to
>dnm at orion.usno.navy.mil.
> 
>I am attaching a list of institutions and persons contacted, except
>for 931 institutions whose emails were obtained from the AAS. I would
>like to apologize to anyone contacted twice, but also appreciate it 
>if you would forward this email to anyone we have missed.  Also, if 
>you are an URSI Commission J national chair, we would appreciate your
>forwarding this email to your complete membership and in particular 
>to the directors of observatories.
>
>Sincerely,
> 
>Demetrios Matsakis
>_____________________________________________________________________
>Dr. Demetrios N. Matsakis           Director, Time Service Department
>(202) 762-1587  DSN 762-1587        U. S. Naval Observatory
>FAX (202) 762-1511                  3450 Massachusetts Avenue NW 
>dnm at orion.usno.navy.mil             Washington DC, USA  20392-5420
>_____________________________________________________________________
>

- --
Poul-Henning Kamp             FreeBSD coreteam member
phk at FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
------- end -------



More information about the tz mailing list