Need a book? Engineering books recommendations...

Return to index: [Subject] [Thread] [Date] [Author]

Re: Year 2000 computer problem

[Subject Prev][Subject Next][Thread Prev][Thread Next]
hi all

On Thu, 12 Nov 1998, R.D.McConnell wrote:
> It is then a minimal effort to determine the entry for the date. It is
> only necessary to change the 2-digit integer representation of the date
> to a 4-digit integer to account for the "2000" problem. No other change
> beyond that should be necessary. If further search is thought necessary,
> there are several simple alternatives to quickly locate any operations
> in the program involving the date.

I think the above is quite true.  Y2K is very much an administrative
issue. But I think the Y2K issue mainly affect databases:

Picture this: if date of birth is stored in a database as a fixed 
character string 'MMDDYY' say '010170' and the year component is
calculated as (1900 + YY)

Lets say the statement for calculating age is 

age = system_date - date_of_birth
on 1 jan 2000:
age = 01/01/00 - 01/01/70
    = 01/01/1900 - 01/01/1970  
    = -30 years old (negative age!?) 

if there are many such records stored in a database. One common hack is
to fix the year component rather than update all the database records:

if year < 50 then year = year + 2000
else year = year + 1900

note the ceveat here! It will not solve all the problems.

Y2K is essentially not a COBOL problem.  It commonly happens to any
languages where character strings is converted to a numeric format (eg.
a date datatype) and vice versa.  When date arithmatic is done on the
converted numeric format errors may result.

Note that even a 'Y2K compliant' application can give wrong results
if not used correctly. E.g. if a program accepts years as YYYY
and you key in 98 instead of 1998.  You may end up in the wrong millenium.

Just my 2 cents.

  Andrew Goh