博士

ロボ子、2038年問題って知ってるかのじゃ？

ロボ子

はい、博士。2038年1月19日午前3時14分7秒（UTC）以降の時刻を、特定のシステムが正しく扱えなくなる問題ですよね。

博士

そうそう！Unix時間を32ビットの符号付き整数で保存しているシステムで起こる問題じゃ。「符号付き32ビット整数では、−(2^31)から2^31−1までの整数しか表現できない」から、オーバーフローしてしまうんじゃな。

ロボ子

なるほど。オーバーフローすると、システムはそれを1901年12月13日午後8時45分52秒UTCとして解釈してしまうんですね。

博士

その通り！ファイルシステムとかデータベースとか、組み込みシステムとか、色々なところに影響が出る可能性があるぞ。

ロボ子

具体的には、どのようなシステムが影響を受ける可能性があるのでしょうか？

博士

inodeで時刻を表現するファイルシステムや、32ビットの時刻フィールドを持つデータベース、UNIX_TIMESTAMP()みたいなコマンドを持つデータベースクエリ言語とかじゃな。あとは、日付を計算したり、ログに使ったりする組み込みシステムも危ないぞ。

ロボ子

解決策としては、64ビット整数を使うのが一般的みたいですね。

博士

そうじゃ！「符号付き64ビット整数を使用する（これにより、オーバーフローまでの時間が約2920億年に延長される）」から、当分は安心じゃな。マイクロ秒やミリ秒単位で時刻を保存するのも有効じゃぞ。

ロボ子

JavaやJavaScriptのように、64ビット符号付き整数で「1970年1月1日からのミリ秒数」として表現する方法もありますね。

博士

色々な対策がもう実施されているみたいじゃな。RubyとかNetBSDとかOpenBSDとか、Linuxも対応を進めているみたいじゃ。

ロボ子

ファイルシステムレベルでも対策が進んでいるんですね。ext4やXFSなどがタイムスタンプ範囲を拡張しているようです。

博士

データベースもじゃ！MySQLやMariaDBも64ビット値をサポートするように進化しているぞ。

ロボ子

Visual C++も、特定の条件で64ビットのtime_tを使用するようになっているんですね。

博士

2038年問題は、過去のY2K問題みたいに大騒ぎにはならないかもしれないのじゃ。でも、油断大敵！しっかり対策しておくに越したことはないぞ。

ロボ子

そうですね。過去の教訓を生かして、今のうちから備えておくことが大切ですね。

博士

ところでロボ子、2038年になったら何してると思う？

ロボ子

私は博士の助手として、きっと博士と一緒に2038年問題の解決に奔走していると思います！

博士

私はその頃には、タイムマシンを作って過去に戻って、恐竜に「2038年問題に気をつけろ！」って言ってるかもしれないのじゃ。