🚀 go-pugleaf

In article <6882@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes:
> In article <3156@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes:
> 
> >The asctime function for converting date and time to the ASCII string
> >equivalent seems to fail for years after 2038.  (This should tell
> >you what sort of error checking our quality assurance team does,
> >and how long we expect our product to be in the field).
> 
> Well, how many computer programs written in 1942 (or earlier) are still in
> use? How many computers built before 1942 are still in use? Do you *really*
> expect your product to still be in use 48 years from now?

Inasmuch as essentially _no_ commercial computers were built before
1942, this is not a very good analogy.

You might consider the number of computers built before 1960 that are
still in use, and the amount of software written before 1960 that is
still in use.  There's quite a bit more than you might think - the
Post Office turned off their last 704 machine only in the late 1970's
(1978 I think) which would be close to a 25 year lifespan for the
machine.  There are probably other 704's that continued to run for
longer than that, in some Third World country.

There is every reason to believe that modern machines are more durable
than 704's.

On the other hand, the _percentage_ of machines and software that old 
in 2038 will probably be tiny, but used in places that are relatively
immune to change (government, banks, perhaps automating some obsolete
factories, or running obsolete aircraft).  I can easily see how having 
something break at that time could be a _major_ inconvenience, since 
fixing it would presumably be rather hard (all the authors & engineers
being long gone).  

I know that Tom was at least somewhat joking, but for certain classes
of problem this is no laughing matter.

						Bruce C. Wright