年始休暇中のある日、私のTwitterアカウントのタイムラインに以下のツイートが流れてきました。
「2022年問題」などと呼ばれ、一部界隈では話題になっていたようです。プログラマーである私も他人事ではないのですが、とはいえこんな実装そうそう転がってないでしょ、と思い忘却の彼方へ。そして仕事始めを迎えたわけですが…まさか自分が当事者になるとは思いませんでした。
1月5日、1通のメールが届く
弊社のサポートデスクに1通の問い合わせが届きました。送り主は、とある受託システムの納品先のシステム担当者でした。内容はというと
今月に入ってからシステムが起動しなくなりました。(※エラー画像添付)
2021年末までは問題なく起動し、利用できていました。
おっと、インシデント発生。しかも起動しないとか、かなりマズいやつですね…
問い合わせがあったシステムは10年以上前に開発されたものであり、ここ数年は安定稼働していたので、急にどうした？と思いつつ、頂いたエラー情報をもとに不具合の原因を探ることにしました。
エラーの発生箇所は早々に特定。実装を見てみると、システムが不正に起動されないよう、暗号化された文字列をパラメータとして渡し、それが正規なものであれば起動するという仕様になっている様子。どうやらこのパラメータチェックでエラーが発生しているようでした。更に内部の関数に潜って見ていくと、なるほど日時を比較してタイムアウトをチェックしています。日時か…日時？
あっ… (察し)
まさかの2022年問題に遭遇
脳裏をよぎるあのツイート。これはもしかしてアレなのか…？もう一度ソースコードをよく見てみます。
//Timeout判定
DateTime dt = DateTime.Now;
string decodeTime = dt.ToString("yyMMddHHmm");
(中略)
if (int.Parse(decodeTime) - int.Parse(codeTime) > Timeout) {...}
現在時刻を取得し、文字列に変換して、さらにそれをint型に変換しています。そして文字列はyyMMddHHmmの型…まさかの予感的中、2022年問題に遭遇してしまいました。古いコードとはいえ、これはちょっと…
やめてくれよ…こんな時限爆弾みたいなバグ仕込むのは…
幸い、影響範囲は小さかったのですぐに修正してデプロイし、エラーが発生しなくなったことを確認できました。
if (int.Parse(decodeTime) - int.Parse(codeTime) > Timeout) {...}
↓
if (decimal.Parse(decodeTime) - decimal.Parse(codeTime) > Timeout) {...}相手方には原因説明とお詫びをし、問題は収束しました。やれやれ。
所感
改めて、自分自身がこの2022年問題の当事者になるとは思いませんでした。やはり他人事と思わず、自分に降りかかるかも、という心構えは持っておかないとだめですね。
しかし、あのツイートを見ていなければ、こんなすぐに原因にはたどり着けませんでした。SNSで知り得た情報に、思わぬところで助けられることって、思い返せば結構ある気がします。情報収集は大切ですね。
