21st Century UN*X - Bugs??

Conor P. Cahill cpcahil at virtech.uucp
Sun Feb 18 02:11:04 AEST 1990


In article <2198 at syma.sussex.ac.uk> stevedc at syma.sussex.ac.uk (Stephen D Carter) writes:
>   As currently programmed not a single system using Unix
>   will be able to come to grips with the 21st Century.
>
>(I have the paper in front of me, so this is verbatim and first hand).

The first part of the problem is that in unix, time is kept as a count of
the number of seconds since Jan 1 1970 (GMT).  This value is kept in a long
integer, which for most systems is a 32 bit entity and therefore has
a maximum value of 4 billion or so.  Since there are 31 million or so
seconds per year, 4 billion seconds can handle approx 136 or so years.

Obviously someone will have to fix this by then.  I doubt you or anyone 
else will still be running any current machine or any current OS at that
time.

BTW- the change to using time_t as the type of the data element that 
keeps track of time is part of an effort to make it easier to change 
the underlying type without adversly effecting software.

>Frankly, if it is true, I'll not mail my order for a Un*x system, but
>will go back to a sensible Operating System.

If you look hard enough you will find that most systems have some built
in limit as to the end of time.  It just isn't necessary to build a OS
that will last for hundreds of years when they will be replaced in 20 or
30.

A second part of the issue is that lots of software has been written
assuming that the year is allways 19xx.  This kind of software is not
limited to UNIX.  When 2000 comes around lots of software will break.

NOTE: If you have any brains, you will already be scheduling your vacation time
to take the months of Dec 1999 and Jan 2000 off. :-)


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+



More information about the Comp.unix.questions mailing list