2000年問題は、年を2桁で扱っていた慣行が原因で、「99」から「00」への転換時に計算が巻き戻る危険が生じた出来事である。米国を含む各国政府は詳細な対策文書を公開し、企業も膨大な検証作業に追われた。結果として大規模障害は限定的だったが、暦の扱いがシステムの根幹に影響することを世界が共有した瞬間だった。ちなみにTechTargetジャパン編集部のある記者は（別のメディアに所属していた当時）、問題が起きると言われたロシアに1999年末に取材で派遣されたが、特に大きな問題は起こらず、マトリョーシカをお土産に年明けに帰国した。

2000年前後：IPv4アドレス枯渇が示した「資源寿命の限界」

　2000年代初頭、IPv4アドレスが枯渇しつつあることをIANA（Internet Assigned Numbers Authority）や地域レジストリが公表し始めた。IANA公式レジストリでは、未割り当てアドレスが日を追って減少し、ついに2011年に在庫が枯渇したことが正式記録として残っている。この問題は、暦や時刻とは異なるが、「有限資源の管理限界」が情報基盤の根幹に関わることを示した例と言えるだろう。

2012年：うるう秒とシステムの脆さ

　地球の自転の揺らぎを反映するため、UTC（協定世界時）には不定期に「うるう秒」が挿入される。2012年の挿入ではLinuxカーネルの実装不具合が表面化し、世界規模のサービス停止が発生した。2022年、国際度量衡総会（CGPM）は2035年までにうるう秒の停止をめざす制度改革を決議したが、実現には今後の議論や調整が必要と言われている。うるう秒は、年問題の枠を超え、“時間”そのものの制度設計がシステム運用に及ぼす影響を示していると言えるだろう。

2020年問題：Windows 7 EOSがもたらした“移行の負荷”

　2020年1月にWindows 7の延長サポートが終了した。情シス部門はWindows 10移行に向けてアプリ互換性検証、端末更新、運用手順の再設計など膨大な作業に直面した。サポート期限は単なる日付ではなく、企業ITにおける一大更改イベントであった。

2025～2027年問題：SAP ERPが象徴する“逃げ切れない節目”

　「SAP ERP 6.0」（ECC 6.0）の保守期限は当初2025年だったが、多くの企業が移行作業に着手できず、SAPは標準保守期限を2027年末まで延長し、2030年末までの延長保守オプションも発表した。SAPはさまざまな移行支援策を用意し、後継製品である「S/4HANA」利用を促している。ユーザー企業は限られる時間の中で今後の対応を決断する必要がある。

2032年問題：Windows 10 EOSによる再移行

　Windows 10は2025年10月に主要エディションのサポートが終了したが、 Windows 10 IoT Enterprise LTSC 2021 (バージョン 21H2) は2032年1月までサポートされるため、企業によっては移行ピークは二段階になる。

2038年問題：符号付き32bit時刻の“技術的限界”

　UNIX系OSが用いる32bit符号付き整数の時刻表現（POSIX time）は、2038年1月19日を上限とし、それ以降はオーバーフローして1901年に戻ってしまう。これはThe Open GroupのPOSIX仕様に示された定義に起因する。64bit化が進むOSでは問題は解消されつつあるが、長寿命の制御装置や組込み機器では依然として注意が必要である。

光格子時計と“秒の再定義”

　国際度量衡委員会（CIPM）は、光格子時計を基盤に“秒”の定義を再構築する可能性を議論している。CCTF（時間・周波数諮問委員会）のタスクフォース報告では、次世代の時間標準の要件や実現方式が整理されている。もし秒が再定義されれば、高精度タイムスタンプが必要な特定のシステムに影響が出る可能性がある。