. 
. 
. 
Last Update: 16/09/1999
Web Author: Trevor Oxborrow
Copyright ©1998-9 Trevor Oxborrow - ALL RIGHTS RESERVED
The Year2000 problem is in fact a design flaw stemming from attempts to minimise data storage sizes when storage was very expensive. Date arithmetic using the two digit year format will produce unwanted and probably unpredictable results when dates from 1st. January 2000 are involved. It is already a problem with systems that look ahead, such as insurance and leasing applications.
The problem was further compounded by programmers who mixed date data and control information. For example, a low value "year" of, say, 0 or 1 would be interpreted as a special flag rather than "1900" or "1901". This would cause results far more alarming than wrong dates!
The Year2000 problem may occur in devices not normally considered to be at risk, as they are not computers. Many items of equipment and appliances have microprocessors embedded in their controls, and those microprocessors may well have a built-in problem. The embedded processor is the hardest to deal with, as it is not usually possible to observe or change the date held. If credible assurance cannot be obtained from the manufacturer that it is Year 2000 compliant, the safest thing is to assume that the device will fail. Examples of devices which may contain embedded microprocessors are lifts, VCRs, washing machines, microwave cookers, fire alarms, environmental controllers, etc.
Critical equipment that cannot be tested or for which the manufacturers cannot give credible assurances should be replaced before 2000, preferably now. There will be a rush to do this in 1999.
Non-critical equipment can be allowed to fail and replaced later.
There is a way round the problem if the equipment can accept a date - the date can be set back exactly 28 years. The calendar of days of the week and leap years is repeated every 28 years, so a calendar setting of 1972 will be identical in most respects to a setting of 2000.
Many PCs will fail to change from 31 December 1999 to 1 January 2000 - they often go to 1 January 1980. However, in the case of many 386 and 486 machines, once the date has been set to a date on or after 1 January 2000, they do retain the date correctly when switched off. This is easy to test, and easy to deal with, since most PCs need not be left switched on over the Millenium Bank Holiday, and can simply be reset on January 3rd, 2000 (or whenever).
Check that your operating system and other bought-in software supports four-digit years. If it doesn't, you won't be able to use any system date commands after 31/12/1999 until you upgrade.
Ensure that the "year" field is not used for control flags or anything other than the year!
Ensure that all date print/display fields are of the form dd/mm/yyyy. This can normally be done in advance of anything else as two-digit years will simply be shown with 2 trailing spaces.
All database date-fields which have dates held in two-digit-year format must be converted to four-digit-year format. If dates are held as integers separately from time, adding 693975 will convert the field to 20th. century four-digit-year form (693975 / 365.25 = 1900). If your system uses a 32-bit signed date/time integer, problems may occur with years from 2038.
Merely interpreting years 00 - 87 as being in the 21st. century and years 88 - 99 as being in the 20th. is to delay the problem, whilst still involving significant code amendment.
Also, check out any log files and any code that processes them.
All date entry code must then accept and validate dates in the new format. Bear in mind that different systems will allow different upper date limits - 01/01/1900 to 31/12/2500 would be acceptable for most 21st. century applications.
Unless your application demands dates over a century apart, it may be worthwhile writing a routine to allow users to continue to enter two-digit years, but convert them immediately into four-digit form. You will need to decide on a cut-off year, which could be automatically linked to the (four-digit) system year. For example, if the cut-off year is "88", a year entered as 01/01/88 will convert to 01/01/1988, whereas 01/01/87 will convert to 01/01/2087.
Test your changes by setting your system date to the year 2000, and running the code.
Test software by setting your system date to the year 2000, and running it, calling all functions into play. Warning - take a full system backup first - you may need it.
If you are not confident that it has Year2000 compliance after this - replace it, or assume the worst and put up with the consequences.
. . .
Last Update: 16/09/1999
Web Author: Trevor Oxborrow
Copyright ©1998-9 Trevor Oxborrow - ALL RIGHTS RESERVED