UNIX 2038 年問題というのがある。西暦 2000 年問題と同じような話である。伝統的な UNIX オペレーティングシステムは日付・時刻を 32 bit 整数値で管理しており，1971 年 1 月 1 日 0 時 0 分 0 秒をはじまりとして 1 秒毎に数値を 1 ずつ増加させる。これを前提としてそのときの時刻を計算している。ところがこの 32 bit データが 2038 年 1 月 19 日 3 時 14 分 07 秒を過ぎると桁溢れし，なんと 1901 年 12 月 13 日 20 時 45 分 52 秒 (UTC) にすっ飛んでしまうのだ。2038 年問題とは，これに伴って UNIX システムでさまざまな不具合が出るであろう事態の総称である。
2038 年なんてまだまだ先だと思う人がいるだろう。でももうこの問題は現実味を帯びはじめている。
私は会社で回覧されてくる他サイトの事故事例には必ず目を通すようにしているが，先日，HP-UX (ヒューレットパッカード社の UNIX) の旧版を使っているサイトでシステム管理者ユーザがログインできなくなるという障害報告を読んだ。ユーザ管理項目に有効期限があり，それに 9999 日みたいな大きな数値を指定したら，有効期限日時が現在の 9999 日後，すなわち 27 年数ヶ月後となって 2038 年 1 月 19 日を飛び越えて 1901 年から折り返してしまい，現時点で有効期限はすでに超過しているとシステムが判断したがゆえの障害だった。ヒューレットパッカード社の名誉のために付け加えておくと，HP-UX 最新版では 2038 年問題は訂正されている。
2038 年問題は世間ではあんまり騒がれていないけれども，UNIX サーバに移行したミッションクリティカルなシステムが極めて多いだけに，これ以上にマズイことも起きる可能性がないわけではない。
西暦 2000 年問題は，多くのシステムが西暦を下 2 桁で管理しているがゆえに 2000 年の判断を 1900 年と誤ってしまうことに起因した。その発現は予想が一筋縄ではなく，大陸間弾道弾が誤動作するかも知れないとか，ジェット機が操縦不能に陥るとか，大いに世間を騒がせた。おまけに西暦 2000 年は 100 でも 400 でも割り切れるので超特例的閏年であったという事情が，計算機関係者の恐怖を煽り立てた。閏日を考慮しない誤った日付計算をした結果，金や法的期限に絡むプログラム不良が発現することを想像すると，システム設計者として背筋が凍る。閏年を「4 で割り切れ，100 で割り切れない年」とする単純なロジックを使うプログラマが実際にいたのである。ふつう 400 年に一回のことを人生で突き詰めて考える人はまれである。関ヶ原の合戦以来のことが自分の人生に降り掛かって来るなんて考える人はまれである。
計算機業界のことを知らない人には，西暦 2000 年問題の大騒ぎについて，2000 年なんていずれ来るのがわかっているのになんでこんなバカな設計にしたんだろう，まったく呆れる，のようなことを他人事のようにホザく輩がゴマンといた。世の愚かな評論家ヅラ連中は皆，このような正論しか吐かない幸せ者である。倫理の悩みのない道徳家である。現象の内在的論理を辿るよりも前に，己の感じ方に満足してしまう人，進化の恩恵に無意識に浴する人の典型である。私の尊敬する米原万里も，どの本であったか忘れたが，西暦 2000 年問題について同じようなことを書いていて，私は正直悲しくなったことを思い出す。もちろん西暦 1990 年代に設計され，それなりの期間使用される予定のシステムならば，2000 年を考慮していないのはただのバカである。
しかし，当時問題になったのはコンピュータ黎明期から少しずつ改修されながら大規模化したシステムだからこそであった。共同体への影響がじつに大きい官庁システムがまさにこれにあたるからだった。私の顧客は，幸いにも，その事情を痛いほど知っており，2000 年対応システム改修にケチケチしなかった。
そもそも，2000 年で問題が出るのがおよそわかっていながら，なんでそういう設計になっていたのか。
コンピュータ機器の進化には，3 年で性能が 2 倍になるという「ムーアの法則」と呼ばれる経験則がある。ここから，2011 年から逆算して 1970 年代あたりに舞い戻ると，かつての計算機が現在と比べていかに貧相なものだったかが想像できるだろう。30 年昔の計算機の性能はいまの 210 （10 = 30 ÷ 3）分の 1，逆にいうと同じもののお値段はいまの 210 倍。40 年前なら 213 倍くらい（13 ≒ 40 ÷ 3）。そう，その当時はメモリ 256KB の一ヶ月の借料がサラリーマン大卒初任給を越えるくらい高価だった。磁気ディスクも同じ。
こういう超高価なリソースを使うとき，とにかくケチろうとするのは当然である。日付・時刻はどんな業務データの属性にも付いて回り，これを仮に short 整数 (2 bytes) で年，月，日，時，分，秒 12 バイト使うとなると，データに占めるその割合はバカにならない。まさかと思う前に 1970 年ごろの 12 バイト，現在の価値に換算すれば 12 × 213 バイトがどれほど重いか考えてみるがよい。いま日付・時刻の格納に一個あたり 12 × 213 (98,304) バイト使わせてもらいます，なんて顧客に言ったら，即刻「バカ」と言われクビである。昔，私の担当したシステムでは西暦を下 2 桁だけで管理し，数字 1 桁を 4 bits に入れて 6 bytes に切詰めていた。理論的にはもっと切詰められるが，計算速度や十六進ダンプ時のわかり易さとの兼ね合いでこうしていたわけだ。それくらい記憶域が貴重だったのである。1970 年代くらいのシステム設計者は，皆，計算理論の前に経済学に縛られていたのだと思う。物事は常にカネに縛られる。
UNIX 2038 年問題についても，なんでたった 32 bit で管理するなんてケチったんだろうと思う人がいまならウヨウヨいるはずである。4 byte 32 bit というデータ構造は 32 bit 計算機がもっとも高速に取り扱うことのできるものなのだ。でも，それを抜きにしても，1970 年ごろの UNIX 設計者は，2038 年にはボクはもう生きていないと無意識に思ったはずだ。人生 70 古来稀なり。そのころにはボクたちのような貧しい資源制約から解放された，もっと夢のようなオペレーティングシステムが動いているさ，と。つまり計算機の世界でも，老人の感慨同様，人生はあっと言う間に過ぎたわけである。
ところで，西暦 2000 年問題はジョークのネタにもなっている。「問い：2005 年のある日，アルバニア軍のコンピュータ系統が一斉にダウンした。その理由は？ — 答え：西暦 2000 年問題」。その国の時代遅れを笑う格好の題材になったんである。でも，2000 年を大きく超過して忘れ去られたころにプチ 2000 年問題が出て恥ずかしい思いをした SE／プログラマは必ずいると私は思う。オレ？ ご想像にお任せする。