2038年問題とは？システム開発時に対策すべき内容を解説します。

システム開発に携わっていると、2038年問題、という言葉を聞くことがよくあります。手垢のついた話題ですが、自分の理解度確認を兼ねて、以下にまとめます。

本記事で分かること

2038年問題とは何か
2038年問題の対策内容はどのようなものか

2038年問題とは
1. 前置き
2. 表現範囲を超えるとどうなる？
対策は？
まとめ
参考リンク

2038年問題とは

前置き

32bitアーキテクチャのマシン上では、C言語のデータ型の1つであるtime_t型は、4Byteデータになります。time_t型は、UNIXエポック秒からの通算秒を表現するもので、表現可能範囲は以下の通りとなります。

表現範囲：-2,147,483,648 ～ 2,147,483,647 (約±21億5000万)

UNIXエポック秒とは、1970年1月1日 0時0分0秒を指し、そこからの通算秒をtime_t型で管理することになります。ただ、表現範囲が上記の通り、+21億5000万秒であり、これを年月日表現すると、2038年1月19日3時14分7秒には表現範囲の上限を超えてしまうことになります。(負数にはなりません。)

表現範囲を超えるとどうなる？

time_t型が符号付きのデータ型です。この上限を超えると、どうなるか？オーバーフローを起こすので、値が負の数になってしまいます。該当の処理が、time_t型データが負数になることを想定した処理になっていなければ、どう振る舞うかが分からないことになります。つまり、システムの不具合につながります。

この問題が発生する原因は、シンプルに、time_t型が32bitであることにあります。

世の中のシステムは、昨今なら、DX化が加速してきていることもあって、古いプログラムは、徐々に対策が進められているかもしれませんが、時限爆弾のようなものなので、今のうちに対策を進める必要があります。

対策は？

この問題は、現状の32bitプログラムを64bitアーキテクチャーのマシンに移植することで解決できます。

64bitのマシンでは、time_t型は、long long型(当方環境:64bit Windows)で実装になっています。long long型は符号付きでも、最大2⁶³-1という大きさになり、ほぼ上限に達することはありません。

以下にポイントをまとめますので、ご確認ください。

POINT!

32bitのプログラムを32bitマシンで動作させ続けると、2038年にはtime_t型のオーバーフローを迎え、不具合を起こす可能性があります。
32bitのプログラムは、早い段階で64bitマシンへの移植を検討すべきです。
32bitのプログラムを、64bitマシンへ移植した場合、time_t型が4Byteが8Byteに変わるので、問題がないかよく確認すべきです。(UTCデータをtime_t型でなく、int型やlong型の変数に格納していたりすると、不具合となります。)

まとめ

2038年問題は、2038年など遠い未来のこと、と考えて、深く考えずに、プログラムを作り散らかしてきた過去の負の遺産、とも言われますが、もう、遠い未来ではなくなりました。

そして、64bitマシンが広く普及した今では、特に意識せずにプログラムを作っていても問題にはならなくなりました。ただ、それは、対策が必要なプログラムのことを理解していない若いプログラマには、盲点となります。過去のプログラムを改造することもありますしね。本来は要らない知識かもしれませんが、古いものも新しいものも、区別なく理解しておくことが、プログラマのスキル評価を分けることになると思います。