振込予定日がなぜか「1989年」に、コンビニATMで不具合

コンビニエンスストアのATMを使って一部の銀行の口座から振り込みをする際、振込予約日の日付がATMの画面や利用明細表に誤って表示されるシステム障害が2019年4月29日までに発生した。振り込みの操作をすると2019年5月7日に実行される予約扱いとなるが、画面や明細表には平成元年である1989年の5月7日と表示される。処理自体は令和元年である2019年の5月7日に正しく実施されるという。

[umaemong]

If wareki = "元年" Then seireki = 1989

[haruyato]

周辺システムはNTTデータ以外のIT企業が開発したとみられ、 ↑ 流石、データ様

[megomego]

テストコード書いてないとか

[whkr]

この日付の書かれた振込完了レシートがメルカリに出品されそう。

[pismo]

第一報で北陸銀行って聞いたときに、北海道銀行もヤバくね？って思ったら提携先の横浜銀行もだったのか。それにしても銀行さん（ネット専業除く）はいつまで元号処理を続けるんだろうねえ。通帳も微妙に不便。

[sjack]

ソースコード見てみたいな。

[daybeforeyesterday]

うーむ

[g0rigor1san]

日付の誤表記だけで済んでるなら良いけど、システムトラブルの対応大変そうですね。関連企業の方、お疲れ様です。

[suika3417]

おっと、こんなところに落とし穴があったか

[ikurii]

渡ってくる日付は和暦だけど、こっちとしては西暦で表示したい。で、和暦→西暦変換をこっちでしてるけど、平成しか想定していないのでこうなった、ということか？ だとすると、令和2年は1990年と表示されるはず。

[topiyama]

時間のテストはないがしろにしがちだと思う（結合試験系では面倒なんだろうけど、だから系を揃えてやりましょう）

[pmint]

令和元年の日付が、一部の処理で平成元年になる不具合。人気コメントにあるような適当なコードを、Twitterあたりで流すだけでも炎上は抑えられそう。嘘でも「誰にでもなんとなく分かる程度の難易度」の情報が効果的。

[kaiton]

やはり、COBOLかな？読める人書ける人が少なくなっているのか？歴史のあるシステムの金融や公共系ではまだか多いと思う。

[mayumayu_nimolove]

こんなレベルのテストをしないとかありえないけどな。あり得るんだな。

[kathew]

コンビニATMに限って安易なバグはあるまいという幻想を打ち砕かれた

[elm200]

面白いなー。1989年は平成元年なので、どこかのシステムは和暦を使っているのかな。きっと複雑極まりないシステムなんだろうなあ。

[KoshianX]

これ改元とか関係なさそうだけどどうしてこうなったんだろ。日付関係はトラップ多くて怖いよなあ……。

[ryunosinfx]

この現場は今現在進行形でどうなってるんやろうな。これNDAがない世界ならGitLabの真似して実況中継したらすごい価値が有るし見てみたい。（Excel方眼紙のWBS片手に怒号が響き渡るなら、それもそれ、That's Japanese Style!）

[mcgomez]

ちょっとタイムスリップSF物の導入部分っぽいエピソードやん。

[peller]

原因となったクソロジックを思い浮かべると呆れる。実装言語やライブラリが悪いのか、その使い手の頭がヤバイのか。まぁ後者なんだろうけど、金をもらってやる仕事のレベルじゃないわな。

[call_me_nots]

“障害が発生したのは北海道銀行と北陸銀行、横浜銀行である。ローソンやファミリーマートのATMを使って同行の口座から特定の銀行の口座などに振り込む際に日付の誤表記が発生”

[isobe-michael]

はてブで答え出てた。

[gui1]

どんまい(´・ω・｀)

[shoechang]

基幹システムをデータが開発したとは言ってない。

[nack1024]

担当者乙

[a8888]

出ちゃったかぁ

[nisisinjuku]

連休返上で祭りだな…ｶﾜｲｿｽ

[mkusunok]

連休中の対応お疲れ様です