March 1999



By Fred Henning

Many software vendors claim that they have 'fixed' their programs so that they are Y2K compliant - whatever 'compliant' means! My definition of 'compliant' would require that every date referenced be 4 digits and every special feature/function relating to dates be 4 digit. I would also accept unique dating concepts. (1)

Windowing is an attempt, by programmers, to mask the problem- not fix it! Windowing uses a window of years, typically 20. The window tells the application to imply that if the year is 00-20 it should be displayed/printed as 2000-2020 – even though the data being stored in the computer is 00-20. The window may be set to continually look ahead (i.e. next year it would be 2001-2021).

Today if you are admitted to the hospital and were born in 1919 the computer would try and make your birth date 2019. I am sure we have 80 year old patients! Hopefully there is also logic that says you can't be here and not born yet! (2)

Some systems today have a 'century' flag. i.e. A check box that indicates, if checked, that the patient was born in 18xx not 19xx. Can we honestly erase all of the flags and reuse them for 1900 vs. 2000? Or do we keep the flag and just never really know exactly what century a 2 digit year refers to, after 12/31/99?

AlexIS uses serial dating (see footnote 1) but it has also implemented windowing as a solution for some applications.

Our upgrade of the DDI Time & Attendance system required us to select 2 or 4 digit years for the interface. We chose to do the extra work and change to 4 digits. (DDI would accept 2 digit years because it thinks we are only getting paid once and doesn't expect to pay us again in 100 years!)

Although a good deal of time and money has been spent so far by ABMC to change out hardware and software that we know has problems, we must rely, to a large extent, on the honesty of vendors when they say that their systems are Y2K compliant. Oh, there is that word again!

I read recently that it is estimated that 80% of the Y2K fixing is done using the windowing concept and not by actually fixing the programs. To me this implies that 80% of the data from now on is questionable. AARP will be losing members every year from now on and administration will be asking Mary Wroblewski why ABMC isn't getting all of the new babies that the Census Bureau says are now part of the population.

This is one time it would have been better for the Federal Government to get involved. Congress should have enacted a law that would require that all software actually provide unique dates. Unfortunately only the Social Security Administration appears to have the Y2K issue under control and that is because they started in 1989 not 99!

(1) I would also accept a serial date concept. In serial dating, all dates are sequential from a given date. i.e. 1/1/1800 becomes day 1. 1/2/1800 is therefore 2 and 1/3/1800 day 3, etc. In this example 1/1/2000 would be 73050 days. (200 years x 365.25 days).

(When computer memory and storage space was very expensive, every extra digit stored cost money. Because of this, only two digit dates were kept. Storing December 25, 1999 requires 8 bytes of memory (storing 12251999). 8 bytes = 64 bits. If you store 73050, in binary format, it takes only 17 bits. The result is the same but the space required is less.)

(2) It might work for Credit Card expiration dates but what about Insurance Policy dates.