2001年9月9日問題
s1g問題(second 1 giga)、または10億秒問題とも呼ばれる。
UNIXタイムが9桁から10桁になることで発生。
PHPではtime()関数ですね。
SQLのデータベースなどで時間の領域確保を9桁の固定領域にしていた場合には問題が起こりました。
例
………
……
………
`created` int(9) NOT NULL default '0'
) ;
C言語のtime_t型がUNIXタイムを使っている。
プログラム内部で数値を10進文字列で扱っていると主記憶領域の破壊、比較の際に大小の不正などが発生することがあります。
UNIXのlsコマンドは、ファイル名が数値であっても文字列とみなしてソートする。
またCGI・Perlも、sortコマンドは「数値は文字列に変換してからソートする」のがデフォルト。
このためファイル名として時間を扱っている場合には問題が発生した。
Windowsでも2001年9月8日よりも後の復元ポイントを利用できないということが起こったようです。
Windows Millennium Edition(Windows Me)のバックアップシステム
「復元ポイントファイル名の算出に使用されるアルゴリズムが2001年9月8日を過ぎると機能しなくなるため」とMicrosoftは発表している。
修正ファイルのインストールで問題は解決するが、
「修正ファイルのインストール前に作成された復元ポイントは，修正ファイルのインストール後，使用できなくなる」という。
UNIX
Solaris の SunDS (Sun Directory Service)
日本ユニシス
USファミリ上で稼動するS-NETBACKUP
ベリタスの一部製品などで問題が報告されている。
TruboLinuxは2000年4月17日にテスト結果を発表し、問題なしとしていました。
UNIXタイムの999999999は
2001年9月9日1時46分39秒
(日本時間で2001年9月9日10時46分39秒)
UNIXタイムの1000000000は
2001年9月9日1時46分40秒
(日本時間で2001年9月9日10時46分40秒)
ちなみに8桁から9桁になった1973年問題は
UNIXタイムの99999999は
1973年3月3日9時46分39秒
(日本時間で1973年3月3日18時46分39秒)
UNIXタイムの100000000は
1973年3月3日9時46分40秒
(日本時間で1973年3月3日18時46分40秒)
