Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.bugs.4bsd
Subject: Re: Leap seconds
Message-ID: <39254@sun.uucp>
Date: 19 Jan 88 10:13:38 GMT
References: <7622@alice.UUCP <1980@rti.UUCP> <16369@watmath.waterloo.edu>
Sender: news@sun.uucp
Lines: 30

> 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.

It was never intended to be used as something for humans to deal with directly.
That's what "struct tm"s are for.

If you want to know the number of seconds that will elapse between two events
(*counting* leap seconds, of course; we all get one second older during leap
seconds just as we do during regular seconds), you should be able to get the
time stamps of those two events and subtract them.  (This is one reason why the
times returned by "time()" should NOT exclude leap seconds.)

If you want to know how much time separates the two events, with the proviso
that e.g. 11:30 tomorrow is to be considered precisely one day after 11:30
today, daylight savings time, leap seconds, etc.  nonwithstanding, you get the
two events dates/times as "struct tm"s and subtract them component by
component.  Similarly, if you want the date/time for "two days from now", you
get "now" as a "struct tm", add two to the current day-of-week value and do the
appropriate "carry propagation" (carefully, taking into account time zone
changes, etc.)

Unfortunately, while UNIX systems have - and ANSI C implementations, barring
surprising changes in the standard, will have - a routine to convert from
"time_t" values to "struct tm" values, most UNIX systems have no routine to go
the other way.  The current ANSI C draft does include a routine that goes from
a "struct tm" to a "time_t"; the spec says that routine has to do the
aforementioned carry propagation.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com