2022年問題に遭遇して解決した話

年始休暇中のある日、私の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で知り得た情報に、思わぬところで助けられることって、思い返せば結構ある気がします。情報収集は大切ですね。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA