Year 10,000 problem

From Wikipedia, the free encyclopedia

The year 10,000 problem or Y10K is the collective name for all potential software bugs that may emerge as the need to express years with five digits arises. In the months leading up to the beginning of the year 2000 (see the Year 2000 problem), the year 10,000 problem was given somewhat humorous exposure by people in the media. This may not be a problem in the year 10,000, as it is highly unlikely that any of the technology or software in use today will still be active at that time (to imagine the technological advances in the next 8,000 years, consider the technological advances in the last 8,000 years). However, it is already a problem today for long term analysis programs, such as software that examines proposals for the long term handling of nuclear waste.^[1]

Contents 1 Problems with date-handling programs 2 Problems with records 3 References 4 Further reading

[edit] Problems with date-handling programs

A lot of date-handling programs during the year 2000 displayed the year as 1800, 1900, 19100, or 100 because the programmers often simply inserted the text "19" in front of a calculation of the last two digits of the year as a shortcut or a way to save memory space. These sorts of date display errors are not likely to occur again when the year 10,000 comes since this type of shortcut isn't useful in this case. However, some programs format dates in a way that only shows the last four digits. This is likely to cause the year 10,000 to appear as "0000".

This problem can be seen today in the popular spreadsheet program Microsoft Excel, which stores dates as number of days since 31 December 1899 (day 1 is 1900-01-01), and the database program Microsoft Access, which stores dates as the number of days since 30 December 1899 (day 1 is 1899-12-31). In either application, entering a date value of 2958465 will correctly format that to the date "31 December 9999" but adding 1 to that to step over to the expected date of "1 January 10000" will cause a formatting error and, in Excel 2000 for example, it will be displayed in the cell as a series of # characters.

Incrementing this value by one causes what the applications call overflow, but in actuality the binary representation of 2958465 is 101101'00100100'10000001, while 2958466 is 101101'00100100'10000010. Both of these values use the same number of bits (22). The overflow that the applications refer to is most likely derived in their floating-point representations (day 1.5 is 1900-01-01T12:00:00 in Excel). They are likely stored as some variant of the IEEE floating-point standard number. The fractional portion of such numbers is 23 bits wide.

The Open Source OpenOffice.org Calc program stores years differently and so has a different problem. It is able to display year 10,000 dates correctly as 5 digit years but the "31 December 32767" is the highest sensible date. This is represented by the number "11274306". If 1 is added to this date to make 11274307 then this is displayed in a date format as "1 January -32768" i.e. the year has overflowed and wrapped to a negative year.

The Long Now Foundation is attempting to foster the custom of writing years with five digits, so that the year 2000 would be written as "02000", which would preempt the year 10,000 problem, but this in turn would be susceptible to the Year 100,000 problem.

[edit] Problems with records

The year 2000 problem came about because two digits were used for four-digit years and the century could not be reliably determined. The years recorded had to have two century digits added to solve the problem. The year 10,000 problem will not require updating any old records because four digits is sufficient for four-digit years. It will only require new records to use five digits. There is, however, a potential problem with record sets that make use of lexical sorting. For example, possible representations dates in the year 10,000 could appear adjacent to dates in the year 1000 rather than the year 9999 as intended.

[edit] References

[edit] Further reading

• RFC 2550: Y10K and beyond — RFC document published as an April Fools' joke in 1999; still, it contains many potentially useful ideas.
• The Y10K Problem, Pascal's Wager, and Petersberg. MathPages: Probability and Statistics. — MathPages notes a similarity between the Y10K problem and both Pascal's wager and the St. Petersburg paradox, stating that the cost of fixing the various Y10K, Y100K, and successive problems is increased in direct proportion to the remoteness of the date, and that therefore each problem should in fact be given equal weight.
• Brad Templeton. Computer systems worry over pending "year 10,000" problem. — Templeton hypothesises the impact of the Year 10000 problem.
• "Beyond Year 2000 Compliance: Year 10,000 Compliance", A/P Recap.
• Lorin May. The Year 10,000 Problem It's Not Too Late to Start.