ア | イ | ウ | エ | オ |
カ | キ | ク | ケ | コ |
サ | シ | ス | セ | ソ |
タ | チ | ツ | テ | ト |
ナ | ニ | ヌ | ネ | ノ |
ハ | ヒ | フ | ヘ | ホ |
マ | ミ | ム | メ | モ |
ヤ | ユ | ヨ | ||
ラ | リ | ル | レ | ロ |
ワ | ヰ | ヴ | ヱ | ヲ |
ン |
A | B | C | D | E |
F | G | H | I | J |
K | L | M | N | O |
P | Q | R | S | T |
U | V | W | X | Y |
Z | 数字 | 記号 |
Microsoft Exchange Serverが抱えていた時限爆弾の一つ。誰も発生を予想しないまま2022(令和4)年に発生して世界中を驚かせた。
「Exchange Server 2016」および「Exchange Server 2019」は、内部で日時を「yyMMddhhmm」形式の10桁の10進数で表わしている(うち分mmのみ+1されているらしい)。
そしてあろうことか、これを32ビットのint型(符号があるため、有効31ビット)に格納するというずさんな設計になっていた。この場合、最大値である0x7FFFFFFF = 2147483647 を超えることができない。
2021年12月31日23:59 = 2112312360 = 0x7DE75428 までは問題が生じなかったため発覚しなかったが、翌年、2022年1月1日00:00 = 2201010001 = 0x8330BF51 になるとオーバーフローしてしまい、以降はメールの配信ができなくなるという問題を発生させた。
何も考えずにint型に放り込むというずさんなコーディングに加えて、2000年問題を通り過ぎて作られたソフトウェアにしては西暦を2桁で表わして2100年問題を発生させることが自明な設計は驚愕に値する。
そしてあまりにも駄目な作りゆえ、設計上生じうる2100年問題よりも前に2022年問題を発生させてしまったわけである。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます