北洋銀行は21日、同行で10月14日に発生したATM障害の原因を発表した。このトラブルでは店内にあるATM462台に約1時間、店外にあるATM358台に約5時間ほど影響が及んだ。リリースによると障害発生の原因として、ATM内部の日付・時刻を管理するプログラムにバグがあった。特定の年月日、時刻にシステムがエラーを起こすようになっていたという。エラーを検知したことでシステムエラーが発生。その結果、ATMの新規受付が自動的に停止したとしている（北洋銀行、日経クロステック）。
10月14日って (スコア:2, 興味深い)
今の北洋銀行が誕生した日 (2008年10月14日, 札幌銀行との合併) [wikipedia.org] ですね。
このときにシステム統合も同時に実施しているようなので、その日だけの特別な処理のどこかに問題があったのでしょう。
# もしかして「今日は北洋銀行の誕生日です！」って出すためだけのロジックだったりして・・・
Re: (スコア:0)
創立記念日が夜間のオートロックのパスワードになってる。ついでに製品のファクトリモード用パスワードも全機この値で統一されてる。ユーザーが知らずにユーザパスワードを書き換えると、ユーザがファクトリモードに入れてしまう。
Re: (スコア:0)
汎用COBOLで「西暦の年から25を引いた下2ケタが昭和の年となります。」の和暦処理が強烈過ぎて他を失念。
関わった銀行証券貸金保険電力鉄道通信その他諸々で日付や期限等で特殊な処理を結構してきたので怖い。
一度限りや年次など遡及して日付を変換処理するだけとか日付に関しては疑問が多い仕様もある。
昭和平成や平成令和の改元で比較する際に一時的に片方に合わせるとか？
5年10年経って彼方此方から調査書類やアンケートが郵送されて来たのはWinny位かな？情報漏洩が社会問題化した時代のアレ。
金融関係は1PGですら試験で400枚入りA4用紙3個入1箱分位の検証資料を出して一発で通る事は稀で何度か差し戻される。
四半世紀後に問題が起きて当時関わった全員い連絡していますとかアンケート用紙を送って来られても困惑する。
運用保守で直近の担当者に「何故気が付かなかった」と吊し上げて飛び降り無い事を切に願う。
特定の日付で発動するバグ (スコア:1)
10月10日10時10分10秒以降になると発動するバグを埋め込んだことがある。
JavaScriptの自前の日付処理の問題で、全桁2桁になると前ゼロ埋めが不要になった結果、文字列連結が数値の足算になってバグった。
秋にプロジェクトが開始して稼働が3末だったので、開発中は全然気づかなかった。
Re:特定の日付で発動するバグ (スコア:1)
日付なんかは、フォーマット系で書式処理するほうが良いよ
マジで何渡してくるかわかんないし。
Re: (スコア:0, 荒らし)
Re: (スコア:0)
あーなるほど。'0'+がなくなって文字列への変換がされないと。
桑原桑原。
やっぱ型に厳密な言語のほうがいいよ（ファィっ！）。
Re:特定の日付で発動するバグ (スコア:1)
型もあるけど、
数値の加算と文字列の連結を同じ演算子にしてるのも問題の一端
Re: (スコア:0)
処理コストは嵩むけど'0'+数値してから、右二文字ってロジックもある。
# 入力が文字列でシステムロケールが変更されてゼロフィルされていても、されてなくてもいけて、同じく型がなく、IFが大変なbatファイルだとこっちのほうが便利。
別ツリーのテストをさぼったからがマイナスモデされてるが、
テストして当然の境界値チェックしてないから言われて当然ですわ。
Re:特定の日付で発動するバグ (スコア:1)
どんな見落としに対しても後知恵でテストして当然と言うのは簡単なので情報量もないし役にも立たないコメントはマイナスモデされて当然
Re: (スコア:0)
テストケースのレビュー時に指摘してくれれば神。
バグ発生・検証後に言ってくるならただの事後諸葛亮。
Re: (スコア:0)
究極的にはあらゆる不具合の未発見はテストケース不足に帰結できるからなぁ
まあ無意味だよな
Re: (スコア:0)
自分なら指摘してるし、テストするからなぁ。
JavaScriptの日時クラスは無駄にサポート範囲広いからシステム仕様でサポートする日付範囲が決まってないならテストが糞面倒臭いよ。
日本国内限定だと、遡っても1873年以降しかサポートしないってしておかないと地獄。
でもうるう秒は入ってこないからマシな部類だと思う。
西暦マイナスは端折るけど、単体テストで境界値とかの
-1/12/31 23:59:59 西暦0年直前
0/1/1 00:00:00 西暦0年(紀元前1年)
0/12/31 23:59:59 西暦1年直前
1/1/1 00:00:00 西暦1年
9/12/31 23:59:59 西暦1桁最大
10/1/1 00:00:00 西暦2桁最小
99/12/31 23:59:59 西暦2桁最大
Re: (スコア:0)
ダックタイピングになれ過ぎですよ…
str(日付)とか何も考えずに無心で入れるのですよ。
ダックタイピングだとたまたまアヒルっぽい哀れな鳴き声を上げた動物もアヒルにされてしまう。
ネタバレ禁止！ (スコア:0)
とある有名推理小説のトリックを思い浮かべてしまう。。。
Re:ネタバレ禁止！ (スコア:1)
ええっと、Red Magic [redmagic.gg]でしたっけ？
Re: (スコア:0)
謎のカウンタが0xFFFFになったんですね
Re: (スコア:0)
すべてがFになったのかな？
辞めた人が (スコア:0)
仕込んだわけじゃないよな
Re: (スコア:0)
条件分岐に見落としがあったなんてね。
2021 年 10 月 14 日 9:29 (スコア:0)
こんな半端な時刻にエラーが発生するロジックを類推するのもまた面白い。
エポックタイムに換算 [epochconverter.com]しても 1634171340 と、この付近で何か起きそうな数字には見えないなぁ。
Re: (スコア:0)
なんかのユニークなキーを生成するのに、テキトーな期日からの時間でもカウントしてんじゃないの？
Re: (スコア:0)
2019年10月14日は体育の日だったので、祝日テーブルでやらかしたとか。
コロナでゴタゴタして、実投入までタイムラグが有ったから実は2年前ブツだったとかで。
9:29の謎は営業時間中なので、最も遅い9時オープンに合わせて9:00以降に時刻同期開始する仕様ならありそう。
次の9:30の時刻同期しようとしたら前回の時刻同期が終わって無くて異常が上がったか、
30分未満というタイムアウトで時刻調整されてないってエラーが起きたか。
組み込みで稀にある「時刻同期は営業日取得を兼ねた初回のみ」みたいな仕様だと、再起動すれば時刻再同期しようとしないのでエラー回避可能。
Re: (スコア:0)
父ちゃん通しで苦肉の策……なんのこっちゃ
Re: (スコア:0)
日時や時刻の割り算の端数とかやって無理数で判定できないとか
そんなしょーもないやつじゃないかな
# なしてそんな無理筋で？ってのは稀に良く見る
Re: (スコア:0)
日付や時刻の数値表現がデジタル化（有理数）されていれば、
割り算の端数では無理数は生じてこないよ。
割り算結果が丸め誤差で正しく表現できないことはよくある。