negative time_t values

[Moderator, John Quarterman]

From: sun!gorodish!guy at utastro.UUCP (Guy Harris)
Date: Sat, 30 Aug 86 20:39:06 PDT

> While it's true that no UNIX files date back to before January 1, 1970,
> there *are* uses for times before that epoch:

Yes, but there are other representations for such dates and times; there's
no particular need to have "time_t" objects represent dates in 4004 BCE, for
example.  Most of the time, they are represented as mixed-radix numbers,
giving year, month, day, etc., or year, day of year, etc..  The standard
arithmetic functions on dates (date1 - date2, date1 + offset, etc.) are
possible, if slightly less convenient, as are comparisons of dates.  Most of
the examples given don't currently use "time_t", as they're not done on UNIX
systems, and there's no good reason to change them and not much reason to
use "time_t" for future programs of those sorts.  ("time_t" is an especially
poor choice for astronomical event databases; many interesting such events
occurred more than 68 years before 1970....)

> I see more use in the short run for being able to record times between
> 1901 and 1970 that I see for being able to record times after 2038.

Yes, but is there a use for recording UNIX file modification times between
1901 and 1970?  Other times can be recorded in forms other than a "time_t".

> In summary:  I'd recommend retaining the ability for time_t variables to
> represent times before 1970.

It's not a case of "retaining".  The 1003.1 Trial-Use Standard says that the
result of "time" represents "the value of times in seconds *since* 00:00:00
GMT, January 1, 1970" (italics mine), and that the values of the time fields
in a "stat" structure are also times since the epoch.  All definitions of
"since" in the Webster's Third in my office indicate that it refers to times
in the future of the associated event, so March 25, 1967, 18:00:00 GMT is
not a time since the epoch and is not a value that "time" will return, nor
is it a time that will appear in a "struct stat" time field.

Assigning a meaning to negative "time_t" values may be straightforward in
that it's done by replacing "since" with "before, at, or since"; however, it
does involve changes to existing UNIX implementations to permit them to be
interpreted as local times (even with table-driven time zone conversion
routines, one has to get the tables right!).  Few, if any, existing programs
deliberately store negative values in "time_t" variables; many of those
programs are likely to want to store times more than +/- 68 years from the
epoch, so liberalizing the meaning of "time_t" isn't going to help them.
They'll have to wait for the hypothetical time in the future when "time_t"
is made a "long long int" or when all 32-bit machines have been replaced by
64-bit machines to make "time_t" useful to them.

Volume-Number: Volume 6, Number 42