2000年問題、2038年問題、
そして
292277026596年問題へ
一元化

本書について

西暦1,999年8月21日、上空を巡るGPS衛星の中で、一つの数字が静かに0へ戻った。週の積算データは10bitで管理され、西暦1,980年1月6日を起点として1,024週で一巡する。設計の時点では充分と思われた桁が、19年余りを経て尽きた、其れだけの事である。然し其の瞬間、受信機は自らが何時に居るのかを見失った──桁は必ず尽きる。本書は、コンピュータが刻む時刻の破綻する日を、西暦1,999年から遥かな未来まで、年月日単位で一元化した記録である。

翌年の元日、世界は一つの数字に怯えていた。メモリが高価であった普及黎明期、使用メモリを出来るだけ少なくする為に、ソフトウェアもCPUも西暦を下2桁で処理する仕様が多かったのである。「00」年を西暦1,900年と誤って認識する事による問題が懸念されたが、発生時期が明確であり、事前に周到な準備が為されていた事から、大きな問題は起きなかった。然し同じ年の2月29日、別の落とし穴が口を開ける。グレゴリオ暦は「100で割り切れる年は閏年としない」「其の場合であっても400で割り切れる年は閏年とする」という二段の例外を持つ。此の例外の例外を書き落としたプログラムは、存在する筈の2月29日を3月1日として処理し、障害を生んだ。

西暦2,001年9月9日1時46分40秒、UNIX時間の秒数が10進法で10桁に達する。秒数を文字列に変換して並べ替えれば、1,000,000,000は999,999,999より小さい──桁が増えるとは、順序が狂う事でもあった。西暦2,004年1月10日には、起点である西暦1,970年1月1日と、32bitが尽きる西暦2,038年1月19日3時14分7秒との丁度中間に時刻が到達し、時間を2倍にする等の処理がオーバーフローを起こす。西暦2,010年には、西暦の下2桁を2進化10進数で扱っていたプログラムが「10」を「16」と読み違え、西暦2,016年として処理したり閏年として扱ったりするバグが頻発した。そして西暦2,019年4月7日、GPSの週の積算データは、二度目の一巡を迎える。

西暦2,036年2月7日6時28分15秒、NTPのタイムスタンプの内、秒を表す32bitが最大値に達し、時刻は西暦1,900年1月1日0時0分0秒へと巻き戻る。其の2年後、西暦2,038年1月19日3時14分7秒（協定世界時）。符号付き32bit整数型で時刻を表現していた全てのOSとアプリケーションが最大値2,147,483,647秒に達し、UNIX時間は西暦1,970年1月1日0時0分0秒へ戻る──2038年問題である。更に西暦2,080年1月1日と西暦2,108年1月1日、MS-DOSのファイルシステムFATは、西暦の下2桁しか扱わないという制約と、年に7bitしか割いていないという制約から、二度に亙って起点の西暦1,980年へと引き戻される。

西暦10,000年1月1日、西暦を4桁で示す事を前提とした無数のプログラムが誤動作する。そして符号付き64bit整数型を用いた場合、時刻の終端は西暦292,277,026,596年12月4日15時30分7秒（協定世界時）に置かれる。宇宙の年齢を遥かに超えた彼方に在る此の日を過ぎれば、時刻はやはり西暦1,970年1月1日0時0分0秒へ戻り、時刻を正しく扱えている事を前提としたプログラムが誤動作する。二桁を惜しんだ黎明期から、64bitという広大な桁を手にした現在まで、人間は問題を解決したのではなく、只管に先送りしてきただけなのかも知れない──本書は、其の全ての期日を一冊に束ねている。