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

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

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

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

I also made various efforts to spread familiarity with the ISO 8601
international date and time notatiuon standard:

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 Kuhn, Computer Lab, Univ of Cambridge, GB | __oo_O..O_oo__

Reply via email to