[mod.std.unix] time_t range

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (08/11/86)

From: dan@BBN-PROPHET.ARPA 
Date:     Thu, 7 Aug 86 10:24:40 EDT

I agree that time_t need not be able to represent times before 1970.
However, I think it's rather short-sighted to say that time_t should never
have its high-order bit set.  That restricts it to representing times
before January 2038.  "UNIX will be dead by then!" you say; well, people
have been predicting the death of Fortran and COBOL for a long time now,
and it still hasn't happened, nor does it show any sign of happening.  In
UNIX's case the fact that it's the first portable operating system is
likely to cause it to continue to exist in some form for MANY years.  Even
if UNIX itself doesn't last until 2038, it will certainly last long enough
that application programmers will find it useful to be able to store and
manipulate future time values later than 2038.  They would undoubtedly
appreciate it greatly if the system library routines supplied with UNIX
worked for those time values.

Personally I believe that time_t ought to be an unsigned long, rather than
signed, but that would probably break a lot of existing code.  Still, we
should avoid later problems by specifying that library routines that work
with time_t values should treat it as unsigned, and should work for the
entire range of possible values.  This at least makes it possible for
careful programmers to get their code right.

Most of the time-related facilities in UNIX have long been marked by
an amazing short-sightedness.  Let's not perpetuate it.

	Dan

Volume-Number: Volume 6, Number 39