Path: utzoo!utgpu!water!watmath!rbutterworth
From: rbutterworth@watmath.waterloo.edu (Ray Butterworth)
Newsgroups: comp.bugs.4bsd
Subject: Re: Leap seconds
Message-ID: <16369@watmath.waterloo.edu>
Date: 18 Jan 88 14:28:24 GMT
References: <7622@alice.UUCP <1980@rti.UUCP>
Organization: U of Waterloo, Ontario
Lines: 48

In article <1980@rti.UUCP>, trt@rti.UUCP (Thomas Truscott) writes:
> 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.

One of the main problems is that time_t tries to be too many things
for too many people and never quite manages to do everything that is
expected of it.

time_t works fairly well as a time stamp for file changes and such
system related things.  It is when it comes to a human interface
that its deficiencies become more apparent.

A library (portable, not-necessarily-unix, etc.) that I've been working
on provides a complementary solution (definitely not a replacement).

The idea is that when a human enters a time he is refering to the time
on his watch or on the wall clock.  If he says "2 days from today", or
"6 months from now", he would expect the date to change but not the
clock.  It shouldn't matter that 2 days from now is actually 1 second
earlier because of a leap-second, or that 6 months from now is actually
1 hour earlier because of daylight saving time, or 4 hours later because
he's moved to a different time zone.
Similarly, asking for the difference in time between "10:15 Aug 17" and
"10:15 Jan 12" should give an answer that is an exact number of days.

i.e. time is kept track of ignoring time-zones, leap-seconds, DST,
or any other complications that might arise in the future (short of
a major change to the calendar).

I haven't yet needed it, but it wouldn't be difficult to add another
function that could give the real difference in time between two
of these times taking into account leap-seconds, DST, time-zones,
and currently known acts of government.

I realize that this idea is hardly original, and is in fact a giant
step backwards.  But for many applications it works much better than
the more precise (and therefore more often incorrect) values given by
the size_t functionality.