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. References to any year 10,000 or Y10K problem cannot at face value be taken to be serious or in jest as there are both legitimate reasons to plan for far in the future dates as well as a number of humorous references.

Contents 1 Practical relevance 2 Problems with date-handling programs 2.1 Commonly used computer applications 2.2 Runtime references 3 Problems with records 3.1 Example record formats 4 Related organizations 5 Humorous references 6 See also 7 References 8 Further reading

[edit] Practical relevance

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. 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]

[edit] Problems with date-handling programs

Many 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".

[edit] Commonly used computer applications

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. As of Microsoft's latest release, Excel 2007, the same issue applies.

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.

[edit] Runtime references

The GNU Fortran compiler, g77, makes reference in Run-time Environment Limits to the Year 10000 (Y10K) Problems when using intrinsic functions with this compiler suite. The problem is simply stated as, "Most intrinsics returning, or computing values based on, date information are prone to Year-10000 (Y10K) problems, due to supporting only 4 digits for the year.". The failure mode suggested in all of the intrinsic functions is that, "Programs making use of this intrinsic might not be Year 10000 (Y10K) compliant. For example, the date might appear, to such programs, to wrap around (change from a larger value to a smaller one) as of the Year 10000."^[2]

[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] Example record formats

The Internet Kermit Service Deamon (IKSD) uses a 4 digit field for the year in the Database Record Format "Date-time fields are right-adjusted within a field of 18 with the leading blank reserved for Y10K".^[3]

[edit] Related organizations

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 pre-empt the year 10,000 problem, but this in turn would be susceptible to a "Year 100,000" problem.

[edit] Humorous references

In the months leading up to the Year 2000 problem, the year 10,000 problem was given humorous exposure by the media^{[citation needed]}, in such forms as the April Fool's Day RFC 2550.^[4]

[edit] See also

• Year 2000 problem - the last major computer related effort in date handling
• Year 2038 problem - the next major computer related effort in date handling
• Long Now Foundation - a group whose focus is the next 10,000 years

[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.