メッセージ

2008年03月29日の記事

2008/03/29(土)2038年問題

遠い未来の話かと思ったら、ついに当方が設計開発したシステムで発生したようで。。orz
Webブラウザである操作をすると、'500 Internal Server Error' で以後の操作が不能になるというので、どこでそうなるか追いかけている最中に、「ある操作」をすると、

Day too big - 47482 > 24855
Sec too big - 47482 > 44047

のメッセージを吐いて Internal Server Error になる、というものでした。
メッセージからして時刻や日付に関する部分であることが類推できるので、それを中心に検証していたら、、
データベース上に 2100年x月x日 のデータを発見。これが原因です。

2038年問題は、どういう問題かというと、現在多用されている Unix / Linux のシステムクロックが 1970年1月1日 AM 0:00:00 からの累積秒数で表現されており、これが 32bit 長のため、このまま何も対策しないと、2038年1月19日 AM 03:47:07 でフルカウントになり、次の1秒で桁溢れになるため、あらゆる誤動作を引き起こす、という問題。2000年問題より深刻とも言われます。
#ちなみにMacOS ではファイルシステムについて同様の問題である 2040年問題があります。

該当システムは、日付部分だけが問題だったので、Unix のシステムクロック(しばしば epoch とも言う)を使わずに、西暦元年1月1日を起算日とする日付(これはユリウス日と呼ばれる)に変換した上で処理することで回避。
ただ、最近のOSは、Unix のシステムクロックを 64bit 長にしているものも出てきているので、流通しているUnix系OSが64bit 長システムクロックになれば、オーバフローは更に2900億年ほど先になるので、その方向で対策はされる模様。
少なくとも FreeBSD 6.x においては システムクロックは 32bit 長表現みたいです。(gcc のバージョンも 3.4 だし。。)
gcc のバージョンがあがった FreeBSD 7.0R ではどうでしょうか。(gcc のバージョンは 4.2.1)


※追記:
簡単に確認できるようなので、早速試してみることに・・・
FreeBSD 7.0R i386版

[1]% date -u -r 2147483647
2038年 1月19日 火曜日 03時14分07秒 UTC
[2]% date -u -r 2147483648
1901年 12月13日 金曜日 20時45分52秒 UTC

FreeBSD 7.0R amd64 版

[1]% date -u -r 2147483647
2038年 1月19日 火曜日 03時14分07秒 UTC
[2]% date -u -r 2147483648
2038年 1月19日 火曜日 03時14分08秒 UTC

少なくともプラットフォームが 64bit だと64bit長システムクロックに対応している模様。。