「2025年の崖」よりもっと深刻な「2038年問題」
はじめに
以下のような記事がありました。
昨年末あたりから「2038年問題」を扱う記事が増えてきた印象です。
以前の記事で「2025年の崖」について触れましたが、今回はこの問題について考えていきます。
そもそもどういう問題なのか
2038年問題はどういう問題なのか？については、上述の記事に加え、すでに様々なところで解説がなされています。ここではその引用に留めます。
2038年問題（にせんさんじゅうはちねんもんだい）は、協定世界時（UTC）2038年1月19日3時14分7秒（日本標準時の場合、1月19日12時14分7秒）を過ぎると、コンピュータが誤動作する可能性があるとされる年問題。
コンピュータの内部で日付・時刻を表現する主な方法に「UNIX時間」という単位があります。ここで表現できる時刻が、日本時間2038年1月19日12時14分7秒に最大値を迎えてしまうのです。
そもそもUNIX時間は、1970年1月1日0時0分0秒からの経過秒数で時刻を表しています。これが2038年1月19日12時14分7秒になると、日付・時刻を示す値が2進数の32桁目に突入してしまうのです。しかし、32桁目は符号を示す位であるため、1970年1月1日0時0分0秒から「マイナス2の31乗秒（約21億秒）」、つまり1901年12月13日20時45分52秒として認識されてしまうのです。
(https://xtech.nikkei.com/atcl/nxt/column/18/00989/121000165/ より)
何故「問題」だと捉えられないのか
これだけ多くの説明がされているのに、2038年問題に関しては、あまり「問題」だと捉えられている印象がありません。それは何故なのでしょうか？ 原因としては
そもそも用語が難しくて概念が理解できない
概念はともかく、「具体的にどう困るのか」よくわからない
随分先のことなので、今は気にしなくてよい気がする
などが考えられます。しかし、それらをさらに突き詰めると
自分に何ができるのかよくわからない
ということに行き着くと考えます。2038年問題は対象があまりにも根源的かつ広範であるため、目先のTodoとして今の自分に何ができるのだろうと考えてしまいます。この点も大きな問題と言えるでしょう。
「ITの知識をつける」だけでは解決しない
ここで、先ほどのWikipediaなどの文章を改めて読んでみます。これらは確かにすべて内容は正確です。しかし、上記の表現を正しく理解できる人はどれほどいるのでしょうか？
たとえば、「UNIX時間」一つとっても難しいと思われます。1970年の1月1日を起点とする…と言われても
「なぜそんな中途半端な時点を『起点（エポック）』にしたの？」
という素朴な疑問も沸くでしょうし、それらを正しく理解するにはUNIXやC言語などが成立する1970年代の「歴史」を学ぶ必要があります。
また、
またC言語でUNIX時間を扱う「time_t」の変数を64ビットに定義していたとしても、その値を利用する他の変数の定義が32ビットにダウンキャストされていると、2038年問題が発生する。2038年問題に対処するには、time_tだけでなくそれをキャストした他の変数についても64ビットなどに定義し直す必要がある。
この辺をみても、2038年問題を理解させるには、結局「time_t」という概念を理解させることが重要であることがわかりますが、そもそも
「time_t」という概念を理解させること自体が大変
です。さらに言えば、それらの概念を正確に理解しても、その知識はあくまで「前提」であって
この問題のソリューションを導き出すのに直結しているわけではない
ということは非常に重要です。極端に言えば「マニアの知識」であって、現場が欲している解決手段ではないのです。
おわりに ~ 我々はどうしたらよいのか
今回は2038年問題について、何が問題なのかについて考えてきました。2038年問題を「問題」として捉えられない理由は「自分に何ができるのかよくわからない」と示しましたが、あくまで2038年問題はシステム的な問題であるため、究極的には
古い32bitの時計を持つ実装を駆逐すれば解決
という意味では、解決方法はある意味クリアです。
さしあたって、今の自分にできることは、このような記事を共有し、まずはリテラシーを上げていくことからなのかなと思います。この点については引き続き草の根でやっていけたらと考えています。
（つづく）
いいなと思ったら応援しよう！
