Newsgroups: comp.std.c
Path: utzoo!utgpu!jarvis.csri.toronto.edu!dgp.toronto.edu!flaps
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: The type of time_t (was: struct tm -> time_t converter wanted)
Message-ID: <8810281846.AA20611@champlain.dgp.toronto.edu>
Organization: University of Toronto
References: <442@grand.UUCP> <8700@smoke.BRL.MIL> <6964@cdis-1.uucp> <9816@haddock.ima.isc.com> <1988Oct22.230215.19411@utzoo.uucp> <26582@ucbvax.BERKELEY.EDU>
Date: Fri, 28 Oct 88 14:46:34 EDT


roland@wheaties.ai.mit.edu (Roland McGrath) writes:
>With the Epoch defined as it is for Unix (Jan 1 00:00:00, 1970), it is
>desirable to have a signed `time_t' type.  Although I didn't, the world
>did exist before 1970.

First of all, negative time_t values don't mean time before time zero.  This is
confirmed by the return value (time_t)(-1) from mktime() which means "not a
time I can represent", rather than 31 Dec 1969 23:59:59 GMT.

Most of all, time_t is for representing events that happen while the system is
running:  the current time, the scheduled time of events in the future
(e.g. alarms, sleeps), and the time of events in the past (e.g. file
timestamps).  It is not sufficient, nor should it be, for representing the
times of all events in human history and future; a more sophisticated, and
larger, representation is required for that.  So any zero-date in the past
is ok, because a file need not be able to have a timestamp predating the
writing of the operating system it is available on.

ajr

--
#define __STDC__ 0