Path: utzoo!mnetor!uunet!husc6!bbn!gatech!mcnc!rti!trt
From: trt@rti.UUCP (Thomas Truscott)
Newsgroups: comp.bugs.4bsd
Subject: Re: Leap seconds
Message-ID: <1980@rti.UUCP>
Date: 15 Jan 88 17:41:13 GMT
References: <7622@alice.UUCP
Organization: Research Triangle Institute, RTP, NC
Lines: 42
Summary: leave things the way they were, or do it right

Dozens of UN*X people have known of the leap second bug in ctime
(and in the inverse routines) for well over a decade.
Whoever wrote ctime (was it dmr?!) did a great job,
but it has suffered bit rot as the years have gone by.
It is a shame that people have been too lazy to fix the leap second bug.
Ctime has worse problems that have not been fixed either.
Ignoring these problems will just delay the inevitable,
and documenting them as a standard will just make things worse.

It is NOT too late to fix these problems, nor is it too late
simply to postpone the issue for future consideration.

In article <7622@alice.UUCP>, dmr@alice.UUCP writes:
> One postulate (not related to time as such) is that it would be rather
> impolite to make everyone change their ctime function to get reasonable
> conformance.  ...
> A third is that time errors in the distant past are considerably less
> important than ones near the present.

Fine, let's redefine EPOCH to be 14 seconds before 0000 Jan 1 1970 GMT.
That is a lot cleaner than "ignoring leap seconds."

Of course if ctime (and its inverse routines) persist in their
ignorance of leap seconds (as the new standard demands)
then we will have periodic glitches in time.
Do people want this from here to eternity?

And then there are the ctime problems with daylight savings time.
There are areas in the US today where ctime gives the wrong answer.
Is that reasonable conformance?
And there will be big problems when the US Congress (or a state legislature)
changes the rules about daylight savings time.
I consider it "impolite" of ctime to give me wrong answers.

The number one flaw in ctime is that there is no mechanism
by which it (and its inverse routines) can cope with future,
unpredictable, changes in the time reporting system.
Once this problem is addressed, the problems of daylight savings time,
etc. *and leap seconds* will magically disappear.

May the root have mercy on my impertinence,
	Tom Truscott