Precisely, what is meant by the Y2k problem and what causes it? Simply put, it is based on the storage of dates by hardware or programs using six digits, two for the month, two for the day and two  for the year. It is the last of these which is the basis for the Y2k problem. Two digits for the year can only store '00' through '99' and programs or hardware which use this format for storage have to assume a proper century prefix. Up until now it was useful and normally appropriate to assume that any date would be assumed to have a '19' as part of the full date. Thus 05/04/40 would be assumed to be 05/04/1940. This of course would make '00' assumed to be 1900 and as the year 2000 approaches, this assumption is obviously no longer necessarily valid. If only single dates were involved, then this would really present very little of a problem at any time a date were used in display or print, since it could normally be interpreted by the user as to whether it was '19xx' or '20xx'. However, when multiple dates must be compared or sorted, then this is no longer the case. Without some external rules, 01/01/00 would always have to be interpreted as being before 01/01/98 thus making 01/01/00, which is meant to mean 01/01/2000 as being earlier than 01/10/98 which is meant to mean 01/01/1998. Thus any program or system which depends on the sequencing of dates will no longer function correctly in all respects.  One other problem  related to the year 2000 has to be mentioned. This has nothing to do with how the dates are stored, but, instead, has to do with calendar rules. Basically, leap years occur in any year evenly divisible by 4, but not evenly divisible by 100 unless that year is also evenly divisible by 400. Thus 1900 was not a leap year. That is, it was divisible by 4 and 100, but not by 400.  The year 2000, however, is a leap year since it is divisible by 4, 100 and by 400. Programs or hardware which do not consider this full set of rules will have some problems starting on February 29,2000. 

What effects then will be caused by both of these problems?

First, and foremost, all of the hype and fear-mongering centered around the failure of all of our possessions, cars, refrigerators etc., and especially electronic equipment which have embedded chips is absolutely false. The vast majority of embedded chips and, in fact, the vast majority of electronic equipment makes absolutely no use of dates and do not store them in any fashion, six digits or otherwise. As a rule-of-thumb, if any device has no means for allowing you to set or correct a date, then it is not dependant on dates and thus will not fail due to a potential y2k problem. Now, does this mean that if a device does use a date, then it will be subject to failure on 01/01/2000. Most likely not. These are, for the most part, single-date devices and the date is primarily one of convenience to the user rather than one which controls the function of the device. Simply put, that even if the date shows as 01/01/00, there is nothing about this set of numbers which has any effect on the operation of the device. If you had failed to set it in the beginning or had set it to 01/01/85 or whatever, the device would simply not care. There are no rules in the device which make use of this date which would affect the operation of the device. As I said, this is simply for the convenience of the user, not the device. Now, I do know of one case where this will present incorrect data to the user and I will talk about that later, But, I repeat again, it will have no, (or almost no), effect on the operation of the device.

Does the mean then that there are no problems? Not at all. Any program which sorts or compares multiple dates potentially has some problems. Bank transactions are a prime example of this. If two transactions are made, one a deposit on Dec 31,1999 and the other a withdrawal on Jan 1, 2000, and both transactions are applied at the same time, then if the bank stores these transactions only with two digits for the year, then the Jan 1,2000 transaction will be considered as having been made first and the Dec 31,1999 transaction as later. If both of these are deposits or both are withdrawals but the balance is such that both are covered, then the sequence of transactions is irrelevant. But, if the 1999 transaction is a deposit and the 2000 transaction a withdrawal, not covered by the existing balance, then there will be a bounced check and possibly a charge for that bounce. A problem, but not a catastrophic one. Errors of this type and magnitude have always been a part of the normal operations due to factors other than y2k and are easily corrected. Is your balance going to drop to 0 because of y2k? No. Your balance is the accumulated sum of all the transactions against your account, deposits, withrawals, service charges, etc. and has nothing to do with what day it is. Are you going to have to pay 100 years of payments to catch up with a loan or credit card? No. Your payment, and its effect, is based on the current balance and  the interest rate. Nothing to do with the date. Conceivably, you could be charged a late fee if the program was not working properly, since it might consider the date of payment as being way overdue, but again this is a problem which can be worked out and is not catastrophic.

Some programs which schedule according to dates will have some problems, others will not. Some of those that will are ones which require some preliminary work prior to the scheduled date Let us say that 3 days before shipment, stock has to be pulled and prepared for shipment. In cases like this, the preparations date in December immediately prior to shipment dates in January could be missed. After the first of the year, this will again not be a problem, since the dates being compared will be in the same year again. Programs which schedule for given dates, but are concerned only with whether or not a given date has been reached will not fail. This is because the programs are simply testing for equality. If your VCR uses mm/dd/yy for its dates and you program it to record on a date(and time) using mm/dd/yy then when those two match, the VCR will start recording. There is one case, however, where this will not work. If your VCR or any other device does not recognize 2000 as a leap year then it might not allow you to put in that date. Mine won't. So I won't be able to program it to record anything on Feb 29,2000. And as an additional result, the Day of the week showing on the front panel will be off for the rest of the year. That will not prevent it from working. Note that this will not stop me from recording. It will simply prevent me from programming the VCR to record at a specific time on that date.

Programs which schedule according to the day of the week might have some problems. If such programs actually think that it is 1900  instead of 2000, then the day of the week will not be in sync. Examples of this might be power generation, (I am actually guessing here),  and certainly would apply to buildings which control heating and air conditioning according to the day of the week. In such a case, the control program might turn down the heat or airconditioning thinking that it is a Sunday and that the building should be relatively unoccupied when, in reality, it might be a Monday and the building full of people. It shouldn't take the building super more than a few minutes to override and adjust. Again, nothing catastrophic. In the case of power generation, if it indeed uses such scheduling, can also be manually adjusted if need be. 

In actuality, most of these examples that I have given are the very ones which have already been looked at and efforts made to correct them. Work has been going on since the early to mid 90s to find and correct these problems.

What about your own personal computer? Some ancient computers, (made 3 or 4 years ago) will not automatically roll over from Dec 31,1999 to Jan 1, 2000. Some of them might not even allow any date beyond 1999. (Although I have never seen such a one).  In the majority of cases, PCs can handle dates well beyond the year 2000. Normally, dates are stored in PCs in what is called CMOS. This is an alterable memory area which is kept alive  by battery, (see below), even when the computer is unplugged. Most PCs have a means of setting the data in this area which includes, among other things, the time and date. The operating system, DOS, Windows 9X, Unix, or whatever, takes the date from this setting. I have two computers where I am now writing this. One of these allows CMOS dates to be set from 1994 through 2099, and the other 1980-2030. In the event that my CMOS battery should fail, or be disconnected accidentally, then when the PCs are restarted, they will use their default settings. One will show Jan 1,1980 and the other Jan 1, 1994. Both will have to be reset to be current. (Other, more serious, things will also have to be reset, but we are not concerned with them here). Interestingly, both systems can be set by software to any date on or after Jan 1, 1980 and when I restart them, the operating systems on both, (DOS, Windows 9X or Unix),  will maintain that date, even though the 1994 system will show 1994 in CMOS. My guess on this is because both actually store the date correctly, but that the one with 1994 has a restriction on its own built-in hardware setting program. In either case, this date is useful primarily for things which the operating system itself is concerned with, such as putting times and dates on files created etc. It is sometimes passed to programs for determining what the date is and if incorrectly set and used in this manner, could throw off some of your data entry programs. I have discovered such a problem in my own programs which I developed where I work. They are written in Informix-4GL and run on SCO Unix systems. The version of SCO Unix which we are currently running is not y2k compliant in two respects. It will not  allow you to change the system date from within Unix itself after 2000, and it doesn't recornize 2000 as a leap year. Fortunately, for me, this doesn't matter as the CMOS allows the date to be correctly set, including Feb 29, 2000 and Informix takes its Current Day date from the hardware, not the Unix, so the programs will continue to work correctly.  Incidentally, Informix has never stored the dates in the six digit format and thus that aspect of the y2k problem simply doesn't exist. I did modify all of my code to help prevent input errors, since Informix does allow two digits as well as four for years on input and the current version that I use would normally interpret that as a 19xx date. So when this happens, my program asks for confirmation, or correction if necessary for any date which it inteprets as being before 1930 . (Addition 9/8/99. These problems have been solved. SCO provided patches to correct them and when applied, they were no longer problems. One bug did show up in the Informix as a result of these patches, One specific construct applied the wrong date according to the leap year rule cited above, It was easy, however, to change the programs affected to work around this.)

Any chip, or system,  which stores a variable date must have some means to keep this date current. If the power is removed, then it will lose it and have to be reset. PCs contain batteries which do this. Thus, any device which depends on storing a variable date, must have means for resetting it, should the power be lost. As an example, I had to change the battery in my car last week. When I put in the new battery, I had to reset the clock which was part of my radio in order for it show the correct date and time. Some devices, such as VCRs and microwave ovens normally do not have battery backup and so, you have to reset them anytime the power is lost. My microwave is an inexpensive model and only uses a time. This time only shows a 12-hour clock and has no way of telling whether or not it is AM or PM. It doesn't care and leaves it up to me to interpret which it is. My clock radio on the other hand uses a 24-hour clock, because it does make a difference whether the alarm goes off at 6:00 AM or 6:00 PM. It, also, must be reset both as to time and AM/PM when the power goes off. Neither care what the date is.

Currently, some misleading information with regard to Windows 9X is being passed around on the internet. 

See: Using Regional Settings to change Windows 9x for the Y2k

As the link points out, the setting for Windows 9X deals only with how Windows displays it own internal date and has nothing to do with the y2K problem. Windows 98 has an additional setting in the Regional Settings Box which allows you to specify how Windows will interpret dates which are input to it. This is a setting which shows a range of dates, the default being 1930 to 2029. Any date input as 00-99 is defined as 19xx or 20xx according to this setting. Thus a date of 01/01/98 will be interpreted as 01/01/1998 and a date such as 01/01/00 will be interpreted as 01/01/2000. This setting can be changed as desired. It is important to recognize that these settings apply only to dates internal to Windows itself, not how programs running under Windows will interpret these dates. Such programs will have to have their own code for interpreting such dates.  I suspect, but don't know, that this would allow programs written for Windows 98 to use this feature to control the date without having to program it into their own code. This would be only a convenience, since most, (but not necessarily all), programs written for the Windows 9X platform in the last few years that use dates take the y2k problem into consideration. Quicken, for instance, interprets 02/01/00 as 02/01/2000 even though it displays as 02/01/00. This is evident by the fact that Quicken sorts its records by date and if it were intepreting it as 02/01/1900 then records with that date would go to the beginning of the list rather than staying in place after 1999 records. (This was in Quicken98, I was not able to test earlier versions of Quicken for this)

What should I do about y2k? First, of all, don't panic. There will probably be some limited problems, but there should be no world-wide catastrophic breakdown. At worst, make preparations that you might for any normal emergency, such as a blizzard. Have some food, bottled water, batteries, cash etc. on hand.  If you have a personal computer, try setting the date to a year after 2000 and then run any programs that you might depend on and test them. The biggest concern that I have is that there will be bank failures due to people attempting to withdraw all of their money based on a panic situation. I have seen this happen with a local bank. It is real. Keep your records! If there are bank, credit card or other problems of this type, you will need them to set the record straight should there be problems. Be wary of people trying to sell you 'survival kits for the year 2000'. These, generally, are the same things that you could buy yourself at local stores being sold for outlandish prices.

Y2k stands for 'Year 2 thousand'. K comes from the word 'kilo' which means 'thousand'.

Recently, the American Bankers Association prepared a sermon which they made available to clergy to try to stem the tide of concern about the y2k problem. For various reasons, this is not being well received, as you can tell by the preface and the responses to the message at the link above. I, personally, think that they made a public relations blunder in actually preparing it as a sermon, rather than simply presenting it as a source of information with encouragement to clergy to pass on information to their congregations. Some people have interpreted the use of  the words fantasy to mean that the bankers consider the whole y2k business is a fantasy. On the contrary, the banks were probably aware of the problem before anybody else and have, indeed, spent lots of money to correct it. What they were calling fantasy was the hype surrounding the situation, not the fact there was nothing to it. The preparations section of this 'sermon' are, basically, sound. On the whole, I find nothing personally objectionable to anything that is said in the 'sermon'. It calls on us to trust in God; good advice anytime. It calls on us to be reasonable and not fall prey to panic or scam artists; also good advice. Certainly, the bankers have a vested interest in trying to calm our fears. If no banking, or other, catastrophe occurs because of y2k then it is best that we have remained calm. As I said above, panic could cause runs on banks which could cause them to fail, even if there are no y2k problems.

Some comments on the year 2000. 

Much has been said and even shouted about concerning the year 2000. Much of this is simply wrong. Take, for example, the commonly held belief that Jan 1,2000 is the beginning of the new century and the new millenium. Wrong! Jan 1,2001 is the first day of the 21st Century and the first day of the 3rd Millenium. This derives from the simple fact that our years are numbered starting at 1. So 0001 AD-0010 AD was the first decade of the 1st century and 1st millenium. 0001 AD-0100 AD was the total of the first century. Every decade, century and millenium begins in  a year ending with '1' as the last digit and  ends in a year with '0' as the last digit, and each such number includes the entire year, not just the first day. Now it is convenient and proper to talk of the decade of the 90s or the 80s or the 1900s, but these designations are not the same as speaking of the 10th decade or the 9th decade or the 20th century. (Notice that these designations are always 1 higher than the numbers that they relate to, i.e. 20th century refers to dates from 1901-2000 and so on).

A second commonly held belief is that year 2000 celebrates the 2000th birthday of Christ (and possibly, the date for his return). Wrong! The current calendar was not drawn up until several centuries after Christ and its inventors made a mistake in the year for Christ's birth. The real date was actually in 4BC, according to our calendar. So the actual 2000th celebration should have occurred in 1996. About His return, I will not attempt to speculate.

Links for more information. 
U.S. Government
Public Technology Incorporated
Microsoft

Return to Wright Family Home Page