Markus.Kuhn at cl.cam.ac.uk
Fri Dec 3 11:33:54 UTC 1999
Dear Mr. Matsakis,
I am answering your questions as an individual software engineer with
experience in the design of software, protocols, application-program
interfaces and standards related to date and time handling in computer
> 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, but I am somewhat uncomfortable with the idea of decoupling civilian
time entirely from the earth's rotation.
>B. Would you be in favor of such a proposal?
I would prefer a different solution: Keep the around three leap seconds
every two years, but drop the |UTC-UT1| < 0.9 s requirement and require
leap seconds to be announced at least 30-50 years in advance. The
advantage of eliminating any unpredictability in the TAI-UTC
relationship within a very generously chosen upgrade cycle of a computer
system seems to far outweigh the disadvantages of having temporary
|UTC-UT1| values of a few tens of seconds, as long as |UTC-UT1| remains
guaranteed to not grow arbitrarily large as history goes on.
- UTC is still long-term locked to UT1 and we will not have to worry
about leap minutes or similar radical corrections in a few hundred
- Much existing software and many standards are already designed to
handle single 23:59:60 leap seconds well. The associated technical
problems will be tremendously simplified by not having to upgrade
leap-second lookup tables more frequently than the life-time of a
devices's software revision.
- Even though the Y2K experience has shown that some rare application
software can be in use unmodified for over 30 years, leap second
tables are today more and more offered by the operating system
environment, where update cycles of longer than 20 years are unheard
- Much existing software and standards would be affected badly should
rarer TAI-UTC changes of more than one second (e.g., a centennial
leap minute) occur.
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
More information about the tz