あれれ？もう12月！？
1年経つの早すぎじゃないですか？
というわけで、今回は年にまつわる問題の紹介です。
Y2K問題（2000年問題）
2000年になることで西暦を下2桁で管理するシステムが誤動作を引き起こすとされた問題。
- 西暦が99→00となるため日時でソートしているシステムで誤動作が起こる
- C言語tm構造体の年は1900年からの年数だが、2000年には3桁の100になるため表示その他での問題
- 2000年は閏年だがこれに対応していないシステムが少なくなかった
- 当時は世界中のシステムが誤動作して核ミサイルが飛び交うような怖いことも囁かれてた((((；゜Д゜)))))))
個人的には担当システムを調査した際に「エラーログのタイムスタンプが100年になるけど修正しますか～？」ってレベルしかなくて拍子抜けした思い出しかありません。
今思うと当時はY2K問題への対策特需で業界も潤ってて良かったんじゃないかと思ったり
2019年問題
GPS衛星に搭載されている時計の10bitの積算週が2019年4月7日に0にリセットされる、これは問題というよりGPSの仕様。
- 1999年8月21日に同様の事象でカーナビに問題が発生しているが、二度目の2019年はさすがに大丈夫との声もある
- GPS搭載機器の製品数や普及台数は1999年当時とは比較にならないため、はたしてどうなるか？
2025年問題
日本の元号が昭和換算で100年になることで起こりうる問題。
- 官公庁では年を昭和換算の元号で扱っているシステムが少なくない模様
2036年問題
基準時間が1900年1月1日で経過秒数を符号無し32bit整数値で管理しているシステムが2036年2月7日6時28分15秒に桁あふれしてしまう問題。
- 時刻を同期するために用いられるNTPプロトコルは桁あふれ後(最上位bit0の場合)は起点を2036年2月7日6時28分16秒に変えて解釈することで回避予定
- 古いWindowsOSも同様の問題が存在するがその頃には使用されていないので問題とはならない模様
2038年問題
1970年1月1日からの経過秒数であるUNIX時間が2038年1月19日3時14分7秒に桁あふれする問題。
- 日時(time_t型)を符号付き32bit整数値(=31bit)として扱っているシステムで誤動作が起こりうる
- C言語の問題でもあるので影響はUNIX系OSだけとは限らない
- ファイルシステムでも更新日時を32bit値で保管しているものがあり、プログラムのリビルドだけでは済まない可能性が高い
- Y2K問題と異なり中途半端な年月日なため、業界関係者以外の理解や周知が難しいとの指摘がある
あと20年以上あるのでなんとかなるでしょう(^人^)
Y10K問題
西暦10000年になると5桁になるけど大丈夫か?という問題ｗ
エイプリルフールネタのRFCもあります:-)