ミネルバの梟は充電後に飛び立つ

2000年問題と2036年問題と2038年問題と（以下略）

以前のコラム「ネットワークで時間を計る仕組み 」をお読み頂いた方は、NTPを元にした時計が現在のコンピューターシステムのかなりの部分を支えていることは察して頂けたと思うが、実はここに大きな問題も潜んでいる。

それが『2036年問題』と呼ばれるものだ。

どこかから「また○○年問題かよ！」という声が聞こえてきそうである。

かつての2000年問題の時は、多くのコンピューターシステムで西暦の下二桁のみを扱い、上二桁を省略していたのが原因で、1999年から2000年になった時に問題が生じたのだが、こちらはもうちょっと根の深い問題だ。

NTP方式では、UTCでの1900年1月1日 0時0分0秒を時刻計算のスタート地点として、そこから「何秒経ったか？」を積算することで現在時刻を算出している。

そして、この積算は32ビット値で計算されているため「およそ2の32乗秒」までしか計算できない。

つまり、上述の起点から約43億秒（約136年）後がゴールであり、それが「2036年2月7日 6時28分15秒」である。この次の瞬間には桁あふれを起こして16秒目からを新たな起点としてリセットされてしまい、誤動作を引き起こすと考えられている。

さらに、UNIXに限れば『2038年問題』というのもあって、これまた時刻を32ビットで計算していたことによる桁数の限界が引き起こす問題だ。

こちらは2000年問題のように、アプリケーションを記述する時に年度表記を簡略化したために起きるのではなく、UNIXシステムでの時間の扱いそのものから発生している。

UTCでの1970年1月1日0時0分0秒をスタート地点として、約21.5億秒後の2038年1月19日3時14分7秒に桁あふれを起こすため、この時間を参照して動くプログラムが対策していなければ誤動作する。

（同じ32ビット扱いでも秒数が半分なのは、符合付き32ビットだと実際に使える桁数が2の31乗になるからだ）

日本独自の問題で言えば『昭和100年／2025年問題』というのもあって、これは、日本の官公庁などで使用しているアプリケーションが内部的に昭和二桁で年度を表現している場合に発生する。（平成になってからも、見えない内部処理は昭和のまま行っているものがある、らしい．．．）

公的文書等における元号表記を「昭和056年」のように、わざわざ三桁で表示するのは非現実的なので、二桁で扱うのが当然だが、そうなると「昭和100年（2025年）」で昭和0年にリセットされてしまい、西暦2000年問題と似たようなトラブルを引き起こす可能性があると言われている。

もっとも、システム自体のOSなどが元号ベースで日付を扱っているはずはないので、これは、アプリケーションにしか起こらない問題だし、昭和の時代に調達された情報システムが現在も稼働している可能性は非常に低いので、その点でも（たぶん）大きな問題になることはないと目されている。

ー

なんであれ、「日付と時刻」というのは60進法と24等分のミックス（さらに12等分でのAM/PMも使用されるが）という面倒な代物であり、特に日付は現実世界の物理的挙動をベースにしているため、1年が12ヶ月の365日で閏年だの閏秒だのときれいに割り切れないものが多い。

そのままではコンピューター的に扱いづらい代物であることは確かである。

なので、どこかに起点を決めて「そこから何秒経ったか？」を基準にしようという発想に至ったわけであるが、初期のコンピューターシステムでは桁数の多い計算というのは、計算や記憶装置の資源をとても（当面は無駄に）消費するものだった。

32ビットでも、多くの計算機科学者は「十分に妥当な桁数」あるいは「現実的な解」だと考えたのだろう。

なにしろ、以前のコラムでも書いたように「copyをcpと、listをlsと記述することを有意義な簡略化」と考えていた時代である。

そして同じ発想で「1975年は誰がどう見ても75年と書けば通じるよね？　て言うか、それ以外の解釈ないよね？」となって2000年問題が引き起こされた。

2036年だの2038年だのは、初期のUNIXシステムやNTP開発当時のプログラマーにとっては（自分が定年退職した後の！）遠い未来のことだったのである。

「人間って学習しないのかな？」と思いたくなるかも知れないが、たいていの人は「目の前の問題」にしか目を向けないものだ。

それがプログラマーやSEであっても、面倒な問題は見て見ぬ振りをするとか、自分の損得に関係ないことは先送りするとか、そういったベースの部分での人間としての挙動というか精神性はまったく変わらない。

わずか数十年後の近未来に発生することが『確定』していた時間計算問題を放置、もしくは見て見ぬ振りをしていたのは、平たく言えば「俺の知ったこっちゃねえ」という感覚でもあるのだが、この先送りを個人の責任に帰すのは無意味なように思う。

これは個人の意思と言うよりも、「目前の効率をなによりも優先する社会」がそうさせたのであり、それは「将来の可能性を重視するよりも、当面の無駄を許さない圧力」として周辺に存在していたはずだ。

さて、細かい問題は他にも色々とありそうなものの、2000年を乗り越えて以降は、西暦を四桁で表すことが一般化したので一安心だろうか？　

いやいや、最後には大物の『西暦10000年問題』が待っている。

となると、8000年後の未来のことを考えて、今から西暦は五桁で表すようにすべきだろうか？

まあ、もしも西暦10000年に高度な情報システムを利用する人類社会が（まだ）存続しているとしたら万々歳である。

きっと、今の私たちとは比べものにならない叡智を蓄えている（はず）と思われるので、この問題は先人に倣って先送りし、未来の人々（もしくはAI）にお任せするとしよう。

　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　

＜　時間の積算を64bitにすると、およそ3000億年までカウントできる。多分これなら足りるだろう。＞

＜　歴史的に見ても、社会・工学的な問題などで結果的に大きなトラブルを引き起こす主要原因は、上述の「目先の効率優先・利益優先」という思考だが、その概念は主に、上司とかプロジェクトマネージャーとか経営陣という、影響力上位の実体に憑依しているものだ。＞