The problem in computers
The Year 2038 problem is similar in nature to the Year 2000 Problem. Design issues result in the production of computer systems which cannot handle dates beyond a fixed time in the future. When a time too great for the storage capabilities of the software is referenced, an overflow or wraparound occurs. The resulting time will be in the past and calculations erroneous.
The Year 2000 Problem, or Millennium Bug, was a design flaw stemming from attempts to minimise data storage sizes when storage was very expensive. Date arithmetic using the two digit year format could produce unwanted and unpredictable results when dates from 1st. January 2000 were involved. 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 Year 2038 problem affects all computer programs and systems that store time as a signed 32-bit integer representing the number of seconds since 00:00:00 January 1, 1970. Times and dates after 03:14:07 UTC on Tuesday, 19 January 2038, the latest time and date that can be stored, will "wrap around" and be seen by programs as a negative number, interpreted as a date in 1901 rather than 2038. The resulting calculation errors will cause problems for users. It fact, it is already a problem with systems that work with future dates, such as insurance, pension and leasing applications.
As early as 2006 there were reports of a problem in AOL's server software, where the program would specify that a database request should "never" time out by specifying a timeout of one billion seconds (just over 32 years). This was after the 2038 cutoff, so the timeout calculation overflowed and produced a timeout date that was actually in the past, causing a software crash. See Wikipedia http://en.wikipedia.org/wiki/Year_2038_problem for further detail.
It is not only computer hardware and software that could be affected. Some file formats contain 32-bit time information, and these files could well exist long after their originating computer has expired.
There is no easy way round the problem. The only real solution is to switch to 64-bit processors, operating systems, applications and file formats. Use of a signed 64-bit value will give a new wraparound date of around 292 billion years.
The problem in equipment other than computers
The Year 2038 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 2038 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 2038. Non-critical equipment can be allowed to fail and be replaced later.
Steps to be taken for systems under your control:
- Check that your operating system and other bought-in software supports four-digit years and signed 64-bit time variables. If it doesn't, you won't be able to use any system date commands after 12/05/2038 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.
- Check out any log files and any code that processes them.
- All date entry code must 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 2038, and running the code.
Steps to be taken for systems not under your control:
- Seek assurances from the suppliers that the product is 'Year 2038 compliant'. Ask them to support their answer with evidence.
- Test software by setting your system date to the year 2038, 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 Year 2038 compliance after this - replace it, or assume the worst and put up with the consequences.
