Re: [LEAPSECS] what is broken?

From: Rick Thomas - Richard <rbthomas_at_farside.rutgers.edu>
Date: Tue, 19 Sep 2000 17:02:03 -0400

It does seem that the major reason for the proposed radical change to
the definition of UTC is to fix the UNIX clock problem.

The irony here is that there exists at least one well thought out
proposal to change (rationalize and enhance) the POSIX standard
regarding system time so that the kernel's internal clock ticks TAI,
(actually TAI plus some offset, which may or may not be zero, or even
known!) In this proposal, the time presentation library takes care of
converting kernel internal time to UTC (or whatever timezone the user
desires.) Ie, UTC is treated as just another timezone.

The only complexity this would add to existing UNIX systems is to
require that they have a table of past leap-seconds, and that
SysAdmins keep it up-to-date as the world turns (but only if they are
worried about POSIX compliance in this -- rather esoteric -- area.)
IMHO, this isn't any more difficult than keeping the table of holidays
(and Daylight saving time transitions) up to date.

The problem is that there does not exist a relevant POSIX committee
any more to accept that proposal and change the standard.

In some ways, this (radical proposal to change the definition of UTC)
is a back-door way to get around the problem of not being able to
change POSIX.

Rick Thomas




On Sep 19, 12:24pm, Steve Allen wrote:

> I'm somewhat dismayed to realize that, other than the Unix system
> clock (which, if one tenth the effort which has gone into
> /usr/share{/lib}/zoneinfo had gone into leap seconds, would not still
> have a problem), this discussion list has not yet been able to name
> and discuss a single system which is more inconvenienced by leap
> seconds than it is by daylight savings time.
Received on Tue Sep 19 2000 - 14:12:17 PDT