2038年1月19日3時14分8秒

あなたが過去や現在、そして近い未来に、32 bit OSを使ったシステム開発に携わっていた場合、16年後のこの時刻が無事に過ぎることを祈っているでしょう。

そして、あなたの作ったシステムが2038年1月19日3時14分8秒（UTC）を過ぎた時、OSの内部時間がロールオーバーすることから起点となる1970年1月1日0時0分0秒からマイナスの時刻に巻き戻りが発生し、おそらくあなたの作ったシステムの時刻の扱いが誤動作する可能性があります。

これはUNIXで時間を取り扱う変数に符号付32 bit整数型の長さしか割り当てていないかったことに因りますが、UNIXとの互換性を維持する代償として、Linuxを含むUNIX派生の32 bit OSの多くがこの歴史的な背景を引きずっています。

各OS対応状況

Net BSDやOpen BSDそしてLinuxを含め64 bit環境でほぼこの問題の対策は終わっており、また32 bit環境でもカーネルでの対応はNet BSD version 6.0、Open BSD version 5.5、Linux kernel version 5.6以降でほぼ終了済みです。

ただ問題となるのが、これらのOSの上で動くファイルシステムやミドルウェア・アプリケーションです。これらは64 bit化された変数で再度ビルドしなおす必要があり、またその多くの場合に単純かつ退屈な修正を大量に求められる事になります。

またRTOS での対応は、Wind River社のVxWorksは時間を早期に64 bitの変数として取り扱っていた為、現在サポートされているすべてのVxWorksは、この問題に西暦3000億年を超えるまで直面しません。このため、実運用上この問題は回避できることとなります。

なお、一部のRTOSなどではまだ対応がされなかったり、起点をずらすなどの回避策で対応してるので、これらの年数を考慮した商品寿命を設定することが必要となってしまいます。

いま出来ること

幸いにもまだ私たちには時間があります。可能であればVxWorksの様に、時刻を取り扱う変数が64 bitの環境で作成された製品に置き換えていくことが最善でしょう。それが難しい場合でもファームウェアアップデートの準備をすることは必須となります。

64 bitの変数に変更してアプリケーションやミドルウェアも修正するか、起点時刻をずらすか、若しくはラッパー関数を作成するか、などいろいろな対応方法がありますが、これは規模やシステム要件によりどの方法が有効かは変わります。

上記の対応や問題の解決に不安があるようでしたら、一度弊社までお問い合わせください。

LinuxやRTOSでの組み込みシステム開発に長年携わってきた弊社のエンジニアが対応させていただきます。

※ この記事は2022年に寄稿しております。

※ Wind RiverおよびVxWorksは、Wind River Systemsの登録商標です。