From: Dan Clemmensen (Dan@Clemmensen.ShireNet.com)
Date: Wed Sep 10 1997 - 19:46:41 MDT
Hagbard Celine wrote:
>
> For those unfamiliar, dates are an important part of the software
> systems utilized by both government and industry. As far as I
> understand, the problem lies with the fact that most software developed
> during the past two decades for mainframes, client/server and personal
> computers recognizes years by only two digits ("96" for 1996) instead of
> four digits. When a date-senstive function requiring the year 2000
> ("00") as operative input is performed, bad things *can* happen
> (crashes, silly results, inaccurate records, etc.) The problem interests
> me insofar as we have less than three years to solve it. Enough time? I
> don't know, and hence this post.
>
The problem is bigger than this in some ways, and smaller in others.
Bigger: much of the older software in question uses 2-digit years. But
software written back then also very often uses the convention that
a "don't know" or "don't care" or "not filled in yet" is coded as
"99". So this class of problem must be solved starting now. Example:
query your sales forcasting database for projects sales 18 months from
now.
Smaller: a lot of operational embedded computers don't CARE what
the date is, and a great many that do, use UNIX time, which is
measured as the number of seconds since 1 Jan 1970. (Apparently,
that was the actual beginning of the universe.) This is carried
as a 32 bit number, which means that the end of the univers is
in Feb 2106.
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 14:44:52 MST