ANSI 'C'.

[Michael Meissner]

In article <171 at watmath.UUCP> rbutterworth at watmath.UUCP (Ray Butterworth) writes
>
>The standard obviously didn't put much thought into anything related to
>times.  They define type "time_t" as an arithmetic type that represents
>the time, and then define a difftime(time_t time1,time_t time2) that
>computes the difference between these two arithmetic values.  Why the
>function?  Does the standard have a new arithmetic type on which the
>operation of subtraction is not allowed?
>And then they define a function gmtime(const time_t *timer) that takes
>a pointer to the arithmetic value, which it is not going to change anyway.
>Why not just take the value itself instead of the pointer?
>

   As a member of the ANSI X3J11 committee, let me point out what I saw as
the reasoning behind this.  First of all, there was great controversy as to
whether the time routines should be standerized or not.  Personally, I was
against them (some systems don't have clocks, there are systems that don't
know the difference between GMT and localtime, and what do we do with a system
in a plane or space shuttle).  As regards to gmtime, it has to be a pointer
because that's the way UNIX does it.  Historically, this is because the
original PDP-11 V6 UNIX (and earlier) did not have the long data type, and
time_t was defined as an array of two integers.  The rational behind difftime
is that the implementor does not necessarily have to store the number of
seconds since Jan. 1, 1970.  Rather the time field could be an arbitrary
encoding, and difftime would allow the user to compare two times portabily
(ie, write a make utility).  As an example of an encoding, Data General's
time field consists of 2 short integers fit into 1 long integer.  The first
is the number of days since Jan. 1, 1968, and the second is the number of
biseconds since midnight.  My C implementation actually uses the UNIX
encoding for ctime/gmtime/localtime, and provides a separate dg_ctime/
dg_localtime, but could conceivably use the native encoding.

	Michael Meissner
	Data General
	...{ ihnp4, decvax }!mcnc!rti-sel!rtp47!meissner