St-Donat    In the heart of the Laurentians
St-Donat view


THE MILLENIUM BUG FIX : Some possible solutions for PC's.

First, let's see if you have a problem with this bug. There are 2 possibilities : Hardware and software.

HARDWARE : As explained on the CNN site (and other sites also), the best way to check your PC is to go back to old faithfull DOS and adjust the date to December 31th 1999 with the command DATE. Adjust the time of the day to 11 :59p (or 23 :59) with the command TIME. Close down your PC and restart it after a minute or so. Recheck the date and if you get 1980 for the year (or worst 1900), then you've got the hardware bug! If you get year 2000, you're in good business!

SOFTWARE : If you don't have the Hardware bug, check your software with the date adjusted in the year 2000. If you get funny results (like balance sheets that don't balance), then you will have to change the code in your software (if you are the programmer) at every instance of a date manipulation. In Quickbasic, for example, you will have to search for every instance of DATE$ and do the corrections. You should have programmed with 4 digits for the year right from the start of your software. I use the japanese date format : YEAR-MM-DD.

When will we stop being shortsighted in computing? Win95 doesn't go more than year 2099. Why not year 9999? Remember the 32Megs limit on hard disk partitioning? And the 504 Megs? And the 2 Gigs? Why not 9999 Teragigs? Why don't we use a flat memory model every time we switch to a new stepping in bits (16 to 32, or 32 to 64)? Yes, Earth is flat. Galileo had to admit it (or else die).

Now for some possible solutions if you've got the hardware bug:

Let's give an example in Quickbasic (you can apply this solution in any type of programming environnement). First, don't bother changing the date when you get to year 2000 (just make sure that you are on Jan 1st 1980). Now replace every instance of DATE$ in your software with this piece of code (Note that this piece of code will not affect computer's who don't have the bug):

Change every instance of DATE$ for REALDATE$ with the code for REALDATE$ being (right at the beginning of your software and at every instance of a date manipulation) :

CASE IS = "198"
REALDATE$ = LEFT$(DATE$, 6) + "200" + RIGHT$(DATE$, 1)

Now use REALDATE$ every time you need to use a date figure in your coding. As we will never come back in the 1980's (unless we do like in the film BACK TO THE FUTURE), this will give you another 10 years to work with this computer.

Once you are in year 2000, you can modify your code again to give another 10 years (20 years total). Here is the code :

CASE IS = "198"
REALDATE$ = LEFT$(DATE$, 6) + "200" + RIGHT$(DATE$, 1)
CASE IS = "199"
REALDATE$ = LEFT$(DATE$, 6) + "201" + RIGHT$(DATE$, 1)

Note : If you get 1900 when you make the test, just replace the values accordingly.

This will do the trick until year 2019, which will give you plenty of time to replace your computer.

If your software needs to know the days of the week (Monday, Tuesday, etc...), there is an algorythm to calculate this, so you will have to use it to be accurate.

Another possible fix is through the manipulation of the DATE function in DOS. I did not check for this possibility myself, but I am quite sure that the DOS command DATE uses an Interrupt Call to make the manipulation of adding 19 to the actual 2 digits date data. Example : 19 + 97 = 1997.

The Interrupt Calls are copied from ROM to RAM for speed purpose and it is possible to replace the code for the Interrupt (Hey! Virus programmer's, it's time to put your skills to good use! Isn't that what you do? Replacing Interrupt 13H code?)

So, by making a small Assembler code and installing this piece of software in AUTOEXEC.BAT, it would change the code to get the date with something similar to the previous Quickbasic code.

This could possibly make the job with mainframes, but I am not sure. As I don't have the time to check for the Assembler fix, I would appreciate some return on this matter, as I would like to include it in this document with your references, be it shareware or freeware.

Hope this will be of some help,

Pierre Forget
19 Place Tournesol
Prov. Québec, Canada
J0T 2C0

Note : These pieces of code are given as is and it is your responsibility to verify your own results.

Now : Where is St-Donat? St-Donat is a nice village in the Laurentians with 2 hughe lakes, side by side. A very nice and quiet (sometimes too quiet : we would need a few software companies here) place to do some coding.

Now here is some interesting links for solutions to the Millenium bug:
You will find an executable on that site that could be a solution for your problem.
A permanent solution to the millenium bug. I am not responsible of the results, but it looks like a very interesting solution.



Site managed by: Pierre Forget Computer Service