2001年9月9日問題
2001年9月9日問題（にせんいちねんくがつここのかもんだい）は、コンピュータシステムにおいて、2001年9月9日1時46分40秒（協定世界時、以下同）に1970年1月1日0時からの秒数が9桁から10桁になることで発生するプログラム上の不具合。
2000年問題をY2Kと略記するのと同様にs1g問題(second 1 giga)、あるいは10億秒問題と表記されることもある。
概要
問題の背景となるtime_t型（1970年1月1日0時からの経過秒数）については、2038年問題を参照。time_t型の値が十進法で9桁(999,999,999)から10桁(1,000,000,000)になることにより、問題の発生が懸念された。
実態
2000年問題が大きな社会話題として扱われたこともあり、多くの企業が2001年9月9日問題対応に関するページを作成したが、マスコミはほとんどこの問題を取り上げなかった。また一方で「秒数を10進9桁を上限とするプログラムを組むことなど考えられない」「トラブルは起こらないのではないか」という技術者の意見もあった。
だが個々のプログラムのレベルでは実際に問題が発生してしまった。確認されたものには
- Yahoo! JAPAN掲示板
- CVSup
- gnus
- Windows Meの『システムの復元』機能[1][2]
- Sun Directory Service（Solaris用）
- Pro*COBOL（Oracle、Windows版）
が挙げられる。2ちゃんねるのスレッドIDにもこの値が使用されていたが、問題は起こらなかった（事前にテストされた）。
これらの原因の多くは1970年からの秒数を文字列表現に直してソートしたことによるものであった。文字列（辞書順）でソートすると「1000000000(10桁)」＜「999999999(9桁)」となり、項目が正しい順番で並ばなくなる。これにより新たに作られた項目が一覧表示されない、所定の動作が行われない、あるいは古い項目と勘違いされて削除されるなどの不具合が起こる。
UNIXのlsコマンドは、ファイル名が数値であっても文字列とみなしてソートする。またCGIプログラミングで広く使われているPerlも、sortコマンドは「数値は文字列に変換してからソートする」のがデフォルトとなっている。
このように文字列ソートがデフォルトになっていることに加え、1970年からの秒数が9桁になったのは1973年3月3日9時46分40秒（1970年から約3年後、以下同）とかなり昔だったこともプログラマが油断するひとつの要因にもなった。今動いているほとんどのプログラムは1973年以降に作られたものであり、これまでの約30年間はずっと秒数が9桁だったために、うっかり文字列でソートしても問題が起こらなかったのである（ちなみに10桁→11桁になるのは2286年11月20日17時46分40秒(約317年後)という遥か先の話で、それよりも先に2038年問題がやってくる）。
