Home > Year 10,000 problem

1 Problems with calculations

The most serious result of the year 2000 problem was errors in calculations that depend on the date, like interest payments. Any program that assumed that the year 2000 was actually the year 1900 would give bad results. This is likely to recur in any program that assumes that the year 10,000 is actually the year 0.

2 Problems with date-handling programs

A lot of date-handling programs displayed the year 1900, 19100, or 100 during the year 2000 because the programmers usually inserted the text "19" in front of a calculation of the last two digits of the year. The same date display error is not likely to occur again because simply inserting digits does not work for both 1999 and 2000, so other methods have been used. However, some programs format dates in a way that only shows the last four digits. This is likely to cause the year 10000 to appear as 0000.

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

4 Mitigating factors

The practice of storing years in fixed-width fields is not as common as it used to be, since the need to save a byte per year stored is not as great as when system resources were shorter. Also, the international date standard, ISO 8601, specifies how five-digit years should be expressed.

5 See also

• Unix time
• The Long Now Foundation, in anticipation of the year 10,000 problem, uses five-digit dates, prepending shorter dates with a 0, as: 02004

6 External links

• RFC2550: Y10K and beyond — RFC document published as an April Fools joke in 1999; still it contains many potentially useful ideas.
• Computer systems worry over pending "year 10,000" problem