Last updated: Wednesday April 01, 2009.
My personal feeling is that the impact of the Year 2000 bug is going to be worse than it has to be. I believe that beginning between September-November, people in general will begin to panic somewhat, trying to prepare all at the last minute. This will place an extra strain on resources. Due to the summer's drought, those resources (primarily foodstuffs) will be somewhat less available than normal. This unavailability will by itself cause prices to rise at least moderately. This rise may fuel more panic, causing prices to rise more than they would in any other year where the nation's heartland saw this kind of drought.
I'm no financial advisor, and this next statement is just an opinion, not expert advice, so of course I assume no liability arising out of use, failure to use, or inability to use this information, but I think it would be a good investment to buy gold now that it's lower than it has been in a long time. I think this because I expect that the panic will run the price of gold up until New Year's Eve, when it will peak. The next day, the price will probably drop again, but not back to current levels.
I am suggesting to my clients that it is prudent to prepare for a 2-3 day loss of city services, including food, water, whatever. Other pundits are suggesting up to 6 months. I believe this is overkill. The extent to which the "overkill-pundits" are listened to will set the level of panic as well as the amount of stress placed on our resources.
On January 1, 2000, credit cards will work. The only problem there might be is the odd electric power loss. Credit cards will work because this industry has had to deal with the problem much sooner than the rest of us. Look at your credit cards. You'll find at least one with an expiration year of "00", "01", or "02". These companies are ready. I suggest you pay as much of your balance off now as possible. I suggest this not only to reduce the interest you pay, but because you may need to use your cards a lot the first week of "double-aught".
From a technological standpoint, the Year 2000 bug (Y2K bug) is rooted in computing's history. Until only recently, and I'm referring to about 1994, computer storage space was expensive and therefore quite limited. Saving space was definitely a virtue. In order to save space, most programs were written with the assumption that entered years were in the 1900's. In the 1960's, programmers also assumed that their programs would have a life span less than 40 years. In most, but not all, cases they were right. The practice of using only 2 digits for the year continued until sometime in the 1980's though the problem had not hit most people's radar screens until the early 1990's. I have personally been aware of the Y2K problem and writing software that was compliant since about 1986.
Knowing when leap year occurs is essential for any program that displays the day of the week, or calculates the number of days between any two arbitrary dates. These programs need to know whether to add 28 or 29 days for February. The tests to determine leap year are as follows:
If a year...
The trouble is that while most programmers were aware of the first two conditions, the third was much less widely known until recently. This will cause affected software not to recognize 2/29/2000 as a valid date.
Adding to the trouble is how widespread the problem is. Potentially every computer in the world that processes dates is affected. Your VCR for instance may not be Y2K compliant. Other automated systems may or may not be affected. If they process dates, they may be affected. If they only process times and days of the week, they won't be affected.
Checking for the Year 2000 problem primarily involves three basic tests. Ask yourself, "Does this device (computer, VCR, microwave, software, etc.)..."
For your computer, several software products are available to check more than just the basics.
If you do in fact have Y2K-related problems, you first need to determine how critical the affected devices are. Is this a device you use every day? Is this a computer performing a business-critical function, or is it your VCR at home?
The next question to ask is, "Would setting the year to 1972 be acceptable?" Dates in 1972 are the same as dates in 2000. So if the device in question is your VCR, and although it knows what year it is, you never really use the year when programming it, just set the date to 1972 (if it will let you) and forget about it until you need a new one.
If that workaround is unacceptable, the next question is, "Can you live without the affected feature(s)?" If your microwave allows you to set the date to begin defrosting something for instance, do you use that feature enough that you can't live without it?
If none of those workarounds have proven acceptable, your only real choice is to upgrade your device. Upgrade to the latest version of any affected software and computer hardware. These should be compliant without problems. If in doubt, check with the vendor prior to upgrading. Be sure that you have the proper system setup as well. For instance, I know of one software/hardware provider that provides on its website a statement of compatibility for all its products. However, I have two clients using this company's software. One has upgraded, the other has not as of this writing, but the version they both were using was not Y2K compliant, even though the company that publishes the software claimed it was. Upon pressing them, they finally admitted that they no longer had the versions of the operating system and application software my clients were using to verify my claims of incompatibility. So take the vendors to task and make sure that the specific versions of your software have been verified by the company. If not, verify them yourself.