<p><b>10000年問題</b>（<span lang="en">Year 10000 Problem</span>，簡稱<span lang="en">Y10K</span>）是所有軟體可能在表示五位數年份時發生的問題的總稱。在2000年問題引起人們關注的一段時間中，10000年問題曾被以幽默的方式被人們在媒體中披露。實際上，在10000年時，由於未來科技及軟體的進步－不再只以少數幾個數字表示年份，這可能不再是個問題。
</p>


<h2><span id=".E9.9C.80.E5.A4.84.E7.90.86.E6.97.A5.E6.9C.9F.E4.B9.8B.E8.BD.AF.E4.BB.B6.E5.8F.AF.E8.83.BD.E5.8F.91.E7.94.9F.E7.9A.84.E9.97.AE.E9.A2.98"></span><span id="需处理日期之软件可能发生的问题">需處理日期之軟體可能發生的問題</span></h2>
<p>許多需處理日期的程式會在2000年時將年份錯誤顯示為1900年、19100年或100年，因為工程師直接在以兩位數記錄的年份前面加上"19"以簡化程式或節省記憶體空間。這類的日期顯示錯誤不太可能在10000年來臨時再度發生，因為這種記錄方式在此時是沒有用處的。然而，部份程式在處理日期時只會顯示末4碼的年份。這可能會導致10000年被顯示為「0000年」。
</p><p>這個問題可以在今日相當普及的試算表軟體Microsoft Excel中發現。因為它以"自1899年12月31日起經過的天數"來儲存日期（以此規則，第1天是1900年1月1日）。在資料庫軟體Microsoft Access中也有同樣的問題。它以「自1899年12月30日起經過的天數」來儲存日期（第一天是1899年12月31日）。在上述任一個程式中，輸入第2958465天會產生日期9999年12月31日。
</p><p>對此數值再加1（即2958466）則會造成程式語言中的溢位（Excel中為顯示一列#號），但事實上，2958465的二進位表示為101101'00100100'10000001，而2958466則是101101'00100100'10000010。這兩個值在二進位中皆為22位數。在這些軟體中提及的溢位問題最有可能是源於它們的浮點數表示法（在Excel中，第1.5天是1900年1月1日的12:00:00）。它們可能被以變種的<b>IEEE浮點標準</b>儲存。而此一部份之數字有23位數的空間。 
</p><p>恆今基金會正嘗試促進以5位數書寫／記錄年份的習慣，以此，2000年將會被記錄為「02000」，如此將能預防10000年問題（一萬年蟲問題），但這將再次遇到100000年問題（十萬年蟲問題）。
</p>
<h2><span id=".E6.9C.89.E8.AE.B0.E5.BD.95.E7.9A.84.E9.97.AE.E9.A2.98"></span><span id="有记录的问题">有記錄的問題</span></h2>
<p>2000年問題因為以2位數字表示4位元數年份，而前兩位的"世紀"年份無法被正確決定而產生。被記錄的年份應該加上2位的"世紀"年份以解決此問題。10000年問題不需要更新任何舊紀錄，因為4位元數字已經足夠紀錄4位元數的年份。它將只需要新的紀錄方式以記錄5位數年份。然而，仍然有一個在使用字典序（lexical sorting）記錄時可能會發生的問題。例如：在表示10000年的日期時，它可能會出現在1000年的旁邊，而不是在9999年的旁邊。
</p>
<h2><span id=".E5.8F.82.E7.9C.8B"></span><span id="参看">參看</span></h2>
<ul><li>2000年問題</li>
<li>2038年問題</li>
<li>民國百年蟲</li></ul><h2><span id=".E5.A4.96.E9.83.A8.E9.93.BE.E6.8E.A5"></span><span id="外部链接">外部連結</span></h2>
<ul><li>RFC2550: Y10K and beyond—一份在1999年愚人節發行的RFC檔案，但是有很多實用的資料</li>
<li>Computer systems worry over pending "year 10,000" problem</li>
<li>某使用者親自測試10000年問題（頁面存檔備份，存於網際網路檔案館）</li></ul><!-- 
NewPP limit report
Parsed by mw1360
Cached time: 20230505213557
Cache expiry: 1814400
Reduced expiry: false
Complications: [show‐toc]
CPU time usage: 0.333 seconds
Real time usage: 0.392 seconds
Preprocessor visited node count: 915/1000000
Post‐expand include size: 211097/2097152 bytes
Template argument size: 860/2097152 bytes
Highest expansion depth: 25/100
Expensive parser function count: 4/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 0/5000000 bytes
Lua time usage: 0.103/10.000 seconds
Lua memory usage: 5704643/52428800 bytes
Number of Wikibase entities loaded: 0/400
--><!--
Transclusion expansion time report (%,ms,calls,template)
100.00%  229.245      1 -total
 31.61%   72.466      1 Template:NoteTA
 26.57%   60.902      1 Template:No_footnotes
 23.44%   53.736      1 Template:Ambox
 19.80%   45.389      2 Template:Lang
 18.07%   41.429      2 Template:Category_handler
 15.81%   36.255      1 Template:年問題
 14.75%   33.812      1 Template:Navbox
 10.78%   24.722      2 Template:Category_handler/numbered
  9.76%   22.379      2 Template:Link-ja
--><!-- Saved in parser cache with key zhwiki:pcache:idhash:340461-0!userlang=zh-tw!zh-tw and timestamp 20230505213557 and revision id 71183467. Rendering was triggered because: api-parse
 -->
**10000 年問題**（Year 10000 Problem，簡稱 Y10K）是所有軟體可能在表示五位數年份時發生的問題的總稱。在 2000 年問題引起人們關注的一段時間中，10000 年問題曾被以幽默的方式被人們在媒體中披露。實際上，在 10000 年時，由於未來科技及軟體的進步－不再只以少數幾個數字表示年份，這可能不再是個問題。

## 需處理日期之軟體可能發生的問題

許多需處理日期的程式會在 2000 年時將年份錯誤顯示為 1900 年、19100 年或 100 年，因為工程師直接在以兩位數記錄的年份前面加上 "19" 以簡化程式或節省記憶體空間。這類的日期顯示錯誤不太可能在 10000 年來臨時再度發生，因為這種記錄方式在此時是沒有用處的。然而，部份程式在處理日期時只會顯示末 4 碼的年份。這可能會導致 10000 年被顯示為「0000 年」。

這個問題可以在今日相當普及的試算表軟體 Microsoft Excel 中發現。因為它以 "自 1899 年 12 月 31 日起經過的天數" 來儲存日期（以此規則，第 1 天是 1900 年 1 月 1 日）。在資料庫軟體 Microsoft Access 中也有同樣的問題。它以「自 1899 年 12 月 30 日起經過的天數」來儲存日期（第一天是 1899 年 12 月 31 日）。在上述任一個程式中，輸入第 2958465 天會產生日期 9999 年 12 月 31 日。

對此數值再加 1（即 2958466）則會造成程式語言中的溢位（Excel 中為顯示一列 #號），但事實上，2958465 的二進位表示為 101101'00100100'10000001，而 2958466 則是 101101'00100100'10000010。這兩個值在二進位中皆為 22 位數。在這些軟體中提及的溢位問題最有可能是源於它們的浮點數表示法（在 Excel 中，第 1.5 天是 1900 年 1 月 1 日的 12:00:00）。它們可能被以變種的 **IEEE 浮點標準**儲存。而此一部份之數字有 23 位數的空間。

恆今基金會正嘗試促進以 5 位數書寫／記錄年份的習慣，以此，2000 年將會被記錄為「02000」，如此將能預防 10000 年問題（一萬年蟲問題），但這將再次遇到 100000 年問題（十萬年蟲問題）。

## 有記錄的問題

2000 年問題因為以 2 位數字表示 4 位元數年份，而前兩位的 "世紀" 年份無法被正確決定而產生。被記錄的年份應該加上 2 位的 "世紀" 年份以解決此問題。10000 年問題不需要更新任何舊紀錄，因為 4 位元數字已經足夠紀錄 4 位元數的年份。它將只需要新的紀錄方式以記錄 5 位數年份。然而，仍然有一個在使用字典序（lexical sorting）記錄時可能會發生的問題。例如：在表示 10000 年的日期時，它可能會出現在 1000 年的旁邊，而不是在 9999 年的旁邊。

## 參看

* 2000 年問題
* 2038 年問題
* 民國百年蟲

## 外部連結

* RFC2550: Y10K and beyond— 一份在 1999 年愚人節發行的 RFC 檔案，但是有很多實用的資料
* Computer systems worry over pending "year 10,000" problem
* 某使用者親自測試 10000 年問題（頁面存檔備份，存於網際網路檔案館）
10000年問題