Rob Seaman wrote on 2003-01-28 23:31 UTC:
> A useful exercise from other mailing lists and conferences and such
> is simply to get to know each other and how we all fit into the puzzle
> under discussion.
OK, here we go:
I'm a lecturer (en-US: assistant professor) in computer science and a
programmer. I developed my strong interest in precision computer time
keeping while I was an undergraduate at the University of Erlangen,
Germany, where quite a lot of work was done in the early 1990s on
improving the xntpd clock synchronization software and its kernel
support in various Unix-style operating systems. This software is today
widely used to synchronize workstations to within better than 1 ms with
UTC.
I contributed minor bits of the early Linux kernel clock code and I am
in-depth familiar with the clock implementations and API issues of
POSIX-compliant operating systems.
I wrote various drafts for revised clock APIs that are under
consideration by various programming language and operating system
standards committees, e.g. see
http://www.cl.cam.ac.uk/~mgk25/c-time/
http://www.cl.cam.ac.uk/~mgk25/uts.txt
for two examples.
I am well familiar with the computer science literature on and practical
issues with clock synchronization in distributed systems at all levels
and have reasonably good contacts with the NTP and Linux-kernel
communities.
I'm also a reasonably well-educated hobby astronomer.
One of my on-going minor time-related battle fields is to convince the
Microsoft NT kernel team to support keeping the battery clock of a PC in
UTC as opposed to local time, to reduce significantly the difficulties
experienced by people who travel with dual-boot laptops between multiple
time zones and/or reboot their machine within an hour after the end of
DST:
http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html
I also made various efforts to spread familiarity with the ISO 8601
international date and time notatiuon standard:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
My views in this discussion:
- I believe that basing local civilian times on either an atomic time
with or without leap seconds will not make any significant difference
in practice (both in astronomy and in distributed real-time
information processing and communication systems).
- There are many very practical engineering solutions known to handle
either case safely, elegantly, inexpensively and reliably.
[I am happy to explain these in more detail on request to anyone who
still believes that leap seconds do necessarily cause any significant
problems in practice.]
- Those who believe that you can't keep a battery clock to UTC as it might
miss leap seconds when it is offline, I'd like to remind
gently that the frequency error of most mass-market crystal clocks is
three orders of magnitude (factor 1000) worse then the frequency
difference between TAI and UT1, therefore this discussion is naive. It
remains so as long as there are no cheap clock oscillators with <<10^-7
relative frequency error on the horizon anywhere. Available clocks
costing less then several tens of kiloeuros behave neither like TAI nor
like UTC at all on their own. They always need to be integrated into an
externally controlled PLL to follow either TAI or UTC, and then you can
run them equally easily with or without leap seconds, just as you
please. This is unlikely to change in the forseeable future.
- Computer software should in practice run on a smoothed version of
UTC (such as UTS) to avoid the rare anormality of the 23:59:60
timestap. Even though this is already widely used practice, it hasn't been
formally standardized yet and therefore isn't done consistently in
practice yet. This issue needs to be addressed in the information technology
communities as soon as the dust has settled in this discussion on
revising UTC, but this is nothing the astronomy or time-broadcast
communities needs to get involved with significantly. It will be purely
a software engineering API convention under the umbrella of different
international standards organizations.
- Since leap seconds do in practice not have to cause any significant
disruptions or complications, I am not convinced that there is a good
case for justifying any modification on the existing UTC standard.
On the other hand, I could live equally well with a TAI-locked
local time. Advantages and disadvantages on either side seem
to hold the ballance.
- UTC ain't broken, so don't fix it.
Markus
--
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Received on Wed Jan 29 2003 - 06:32:46 PST