10周年のSPコンテンツ!
221
RAO(らお)@関けも8[き-26] @RIORAO
今のローソンATMは過去に振り込めるのか… pic.twitter.com/SaLNNTZZPR
拡大
Sally @sally_taso
あ、これはヤバいね(
RAO(らお)@関けも8[き-26] @RIORAO
ある意味一生に1回見れるか見られないかの画面なのでATMの画面を撮るという一生に1度するかしないかの奇妙な行動をしてしまいました。取引される方は念のため利用明細は必ず保管しておくといいかも!
SA.net @SA1028
@RIORAO どちらの銀行のカードでご利用になりましたか?
さるじお @saruzio
でちゃいけないバグでしょこれ……こわ……
これどういうこと?
Shavarkoon @Shavarkoon
もしかして令和元年と平成元年(1989年)を読み違えている・・・?
Quappa-El @quappael
元年フラグだけ立って令和更新が上手くいかず平成元年になっちゃったのですねぇ…。
K.N @n_koppe
まさかATMの内部処理は元号…!これは悪夢。
島津弥七@皇國日本(令和の平和) @shimazuyashichi
@RIORAO 2000年問題のバグかな?パソコンのタイマー1970年から19年の1989年。2000年からの19年の2019年と計算したらそんな感じ。令和年号対策のときにやっちゃったか?
村長 @son_tyo
@shimazuyashichi 昭和→西暦が+1925、平成→西暦が+1988、令和→西暦が+2018なのです。恐らくディスプレイだけだと思うのですが令和対応されてないのでしょう。 根幹に影響あって改修が難しくとも、和暦31未満の場合→+2018と判定加えるような逃げ道はあると思うので、多分見落としなんでしょうねぇ。
帽子屋 @boshiyasaaan
@RIORAO 元号で処理する理由がわからんのよね あと、開発時点でバグに気づかなくても、ゴールデンウィークまでにバグチェックしてそうなもんなのに…
JO1NLP@9/22は秋コレ12 @JO1NLP
@boshiyasaaan @RIORAO 全て西暦管理で、プレゼン層だけ元号変換するならこんなこと起きないですね。
クロミミ@アズレン始めました @kuromimin
修正パッチ漏れだろうなぁ‥R1をH1って認識しちゃっているんだろう
なぎ @nagi19780718
@RIORAO 46年前の最新ニュースも届く時代です 過去に送金ぐらいできますよ きっと pic.twitter.com/qmAmeZbqLx
拡大
IMD555 @IMD555
過去の自分に送金!!!
ann@秋例大祭_け32a @ann_momitsu
平成が終わると平成が始まるループ物かな?
rhythmsift @rhythmsift
おそらく内部処理が「令和元年」と「平成元年」を取り違えていて、そしてそこからの西暦表示直しでのミスかぁ…もしも本当にこれで過去への振り込み処理ができれば受け取った人は当時の高金利引いてくるのででウハウハだわ twitter.com/RIORAO/status/…
ステラver.2.1 @stella2kai
@RIORAO 過去の自分の口座に振り込む→現在の残高が増える→過去の口座に振り込む→現在の残高が増える→過去の(ry か ん ぺ き
ぷくりん @Punkupuk
@RIORAO @hu_cravit ATMの話題でこんなに興奮したことはない。
全然笑えない ↓

(最後尾に追記あり)

残りを読む(16)

コメント

ヒジャチョンダラ @citabow 2019年4月28日
30年前に入金されたとしても普通預金だとカスみたいな利子しかつかないけど、10年前の始まったばかりのビットコインを10万円分買ったことにはできないものか(笑)。
ゆゆ @yuyu_news 2019年4月28日
まさか西暦でバグるとは。30年分の金利はどう処理するつもりなんだろうか。
mikumiku_aloha @mikumiku_aloha 2019年4月28日
コンピューターやSI系の一流企業に勤めていて会社としては10連休なんだけど、関係者は元号切り替えのために緊急呼び出しに備えて連絡体制とかやっていたりするのかなぁ
眠れるミソサザイ#@中途半端な暑さで意識が飛ぶ @marumasa58 2019年4月28日
これはきっと表示だけのバグなんだ……担当者は少し直してすぐ帰れるんだ……そうだと言ってくれ……
Eupho @EuphoExige 2019年4月28日
職種によっては笑えない…
石喰い鴉 @ka_la_ss 2019年4月28日
さすがにこれはGW関係無しに対処してくれるよな?
Naruhito Ootaki @_Nekojarashi_ 2019年4月28日
テストしてないのか? こんな面に堂々と数字が出る部分でこれはひどすぎる。
マシン語P @mashingoP 2019年4月28日
通帳や当座勘定照合表にも平成元年表記で印字されたとしても、債権が時効で消滅するから利用法を思いつかないな。
☘🌿こしょこしょ民👁👂🏻👅👃🏻🤸🏻‍♀️📝 @irodori_fanboy 2019年4月29日
表示部だけだから優先順位は低いよね。 優先順位が低い案件はいつの間にか記憶からこぼれ落ちやすいよね。 そうだよね・・・ よね・・・
mikumiku_aloha @mikumiku_aloha 2019年4月29日
marumasa58 表示だけのバグでも再発防止策含めた謝罪をローソンの偉い人に受け取ってもらうまでは過酷な日々と思われ
赤木智弘@真実の赤(白) @T_akagi 2019年4月29日
これ、本当に「表示だけの問題です」とは言い切れないからな。
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
あ・・・ 担当SE呼び出されてるやろなぁ、胃が痛くなるよー
FX-702P @fx702p 2019年4月29日
よーしおじさんバグチェックしちゃうぞー
まづ🐉🏝 @netabare_yan 2019年4月29日
絶対表示だけの問題じゃねーよなこれ。元号から西暦に逆算してるところで、元号を固定値にしてるのが理由なんだろうなーわー大変だー(gkbr
だらず @darazu_kansen 2019年4月29日
タイムリープしてるかもしれない。今ゲームボーイが新発売されてないかッ?!
フシハラ @Fushihara 2019年4月29日
これ100円振り込んで後からどんな連絡が来るかワクワクするのも悪くないな
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
金融系はアカンのや、再発防止策と報告書まとめて上位会社に報告、他に同じようなバグがないか全チェック 処理系が間違っていた場合金融庁からお叱り受ける、吐きそうや
フシハラ @Fushihara 2019年4月29日
政府は「既存の修正含めてシステム内部は全て西暦を使うこと」通達出して。
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
[c6232602] 大手メガバンクなんてスパゲッティ&スパゲッティよ、古い会社や公官庁ほど昭和のプログラムが生きてるのよ
眠れるミソサザイ#@中途半端な暑さで意識が飛ぶ @marumasa58 2019年4月29日
mikumiku_aloha 受け取るまでが仕事じゃなくて、修正版を受け取ってもらった上で他のバグが無いかひたすらデバッグの可能性が高い
mikumiku_aloha @mikumiku_aloha 2019年4月29日
現実的には守るの無理な管理と日程だったりすると管理を誤魔化すのが常態化するから、管理が厳しければ厳しいほどシッカリ出来るというわけではなく。
テレジアさん(Theresia) @Theresia 2019年4月29日
原因究明と直すのとテストに2日以上かかって、令和が来てしまう予感。
Hacchi @2mocccck 2019年4月29日
juEsJsX5eMoEbxx ローソンのATMを銀行扱いするのもどうかと思ってコメント消しちゃったんですけど、言われてみればみずほの案件とかあるし銀行だから大丈夫ってのはただの先入観だったみたいですね…。
mikumiku_aloha @mikumiku_aloha 2019年4月29日
marumasa58 「起きてはならない」レベルなので、修正版は受け取ってもらって一通りの作業が終わっても、同じことを再発させないための防止策というのを提示して「二度とおこさない」ということを客に納得してもらうまでは社内で針のむしろになりそうだなと
RAIYA@提督 @RAIYASB 2019年4月29日
mikumiku_aloha 当然なんだよなぁ 下手すりゃDCに缶詰状態よ
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
mikumiku_aloha 再発防止策って言うけど大抵チェック項目を増やすかチェック体制変更するかしかないんだけどね、賠償まで行かないことを願うよ
あっぷ さん @App__ 2019年4月29日
悪いこと言わないから、改元前後は不要不急の振込とかせず、口座残高チェックを黙って実施すべき。銀行システムにとっては中々のイベントなので、こんな程度は可愛いと思えるような大ボスが出てくる可能性あり。30年前の改元とはシステムの影響も普及度も比較にならないからね、今。なんだけど、一部業界のシステムではかなり根っこの部分で和暦は確実に生きてるから
mikumiku_aloha @mikumiku_aloha 2019年4月29日
juEsJsX5eMoEbxx 増えすぎたチェックが形骸化したり事実上無理なことだったりして現場の人間がチェックの効果を信じないで誤魔化すようになると管理が厳しいハズの業務でありえない問題が起こるので逆効果の可能性もありますが、実際は管理厳しくします方向でしょうね。
mikumiku_aloha @mikumiku_aloha 2019年4月29日
皆さんご存知の通り新元号の発表が遅すぎるという問題指摘はあった。 https://togetter.com/li/1228309
LCO @f_lco 2019年4月29日
あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
割と本気でバグの内容次第じゃ人飛ぶよねこれ
yuki🌾4さい⚔ @yuki_obana 2019年4月29日
どっちにせよあかんので(´・ω・`)詰んだ詰んだ
mikunitmr @mikunitmr 2019年4月29日
そっかー、このバグにより、受け取る際に利息までついてくるのか!!(ならない)
PYU @PYU224 2019年4月29日
色々とダメみたいですね・・・
mikumiku_aloha @mikumiku_aloha 2019年4月29日
平成から令和へと改元越えの振り込みを考えると、改元前に改元対応済のシステム改修をリリースしないといけないので1ヶ月よりさらに短いはずか。このシステムはいつ改修したんだろう?
rice_of_sato @gohan_of_sato 2019年4月29日
これ、改元対応後のモジュールで起きてんのかな。
風祭司 @whoxi4 2019年4月29日
みずほ銀行はこういう事に備えて全部西暦表示に変更された(なお、全部作業終了したとは言っていない)
fishburgerman @fishburgerman 2019年4月29日
5月1日になったら出なくなるバグな気がする。それまでに直せるのかどうか。
クリスセドン @sedooooooon 2019年4月29日
おまえタイムリープしてね???
cocoon @cocoonP 2019年4月29日
かなり前から発表することに抵抗した日本会議に賠償請求しよう
愛媛人と大阪人のハーフ @TmtRj 2019年4月29日
実際に見ると嫌な感覚をおぼえるな
ふじつぼ(Fujitubo) @Chuo_Sobu_Line 2019年4月29日
正常に振り込めるかの確認はしてほしいところ。
きたあかり @kita_akari0420 2019年4月29日
1989年に時間遡行してメガドライブミニが発売される
数奇屋勝手屋 @korekuutokooru1 2019年4月29日
門外漢からすると、振込日から次営業日までの計算で、しかも最終的な表示が西暦なのに元号から計算してるのがまず謎なんだが
空弁者 @scavenger0519 2019年4月29日
【新元号】改元のシステム改修で慌てるシステム屋は「無能」とのこと - Togetter https://togetter.com/li/1306814
ななし @nanasi300 2019年4月29日
そもそも新元号なんていらん。
近藤吉典 @tuoKb2XBrCPRjhV 2019年4月29日
な~んだ、ATMのバグか!彼は家に帰りテレビをつけた。こんにちは、1989年5月7日のニュースです。
Hacchi @2mocccck 2019年4月29日
いろいろ調べてみたけど、勘定系の新しいシステムって「いまメインフレームに入ってるアプリケーションをそのまま徹底流用できます!」とか謳ってるんだな。いくらガワが新しくなってても根っこは古いまんまの可能性があるのか。もしかして昭和歴→和暦→西暦でバケツリレーしてたりするのかな。
希望 @nozomi_crs 2019年4月29日
5/1は念の為いつでも出られるように待機させられる人多いんやで・・・
案山子 @Scarecrow_AP 2019年4月29日
こんなことが起きるからもっと早く公表を・・・という要望だったのよね
希望 @nozomi_crs 2019年4月29日
内部データは和暦で管理→画面に表示するときに西暦変換とかやってるとこうなると思われ
カントク @sige001621 2019年4月29日
北陸銀行のHPには「コンビニATM(イーネット・ローソン)における改元に伴う障害発生について」と書かれている。出力電文ごとに日付計算してるってことだよね?共通処理じゃないことに驚きを隠せない。。。
trueよりも浅い場所 @ibaranika 2019年4月29日
実際、銀行のシステムって過去に振込処理するのって可能なんすよ。人為的に間違えたのを訂正する時とかね。そして預金で過去の訂正をすると、利息も再計算されるんで、そこでさらにミスると事務処理がすごく大変なことになります。ただそういう変則的な処理は普通はどこも役職者の認証が必要なはずなんで、通らないとは思うんですけど、振込出来ない場合はそれはそれで問題だからなあ
saku @sakuuuuuuune 2019年4月29日
このレベルのだとGW返上で済むかどうかも怪しいのでは? 表面的なバグじゃなく、もっと奥の潜在的なバグでしょこれ
saku @sakuuuuuuune 2019年4月29日
mikumiku_aloha 印刷系は大変だったろうけど、プログラムならDBで管理するなりして、仮文字で開発はできるのだから、それは言い訳にはならないなと
希望 @nozomi_crs 2019年4月29日
ああコンビニATMだと提携前提だからATMの日付じゃなくて取引のたびに各金融機関のサーバからデータ受信して表示している可能性も考えられるのか・・・とすると設置しているATMよりもサーバのほうに問題があるってことか・・・色々想像は出来るけど難しいな。
地銀のシステマン @chigintech 2019年4月29日
北陸銀というとMEJAR使ってるけど共同化行の横浜北海道七十七東日本は大丈夫なのかな?
しぇりりん(令和の次はがんばる) @m_sheririn 2019年4月29日
こういう事例、氷山の一角な気もしてきた…まだ改元まで一月の余裕があったけど当日発表なんて意見とかもあったと思うとゾッとする…
ばにやまだ @baniyamada 2019年4月29日
まゆしぃの懐中止まってるー…
鹿 @a_hind 2019年4月29日
担当SEの10連休終了のお知らせ
ひょろ @ihyoro 2019年4月29日
担当SEのGWが消失って言ってる人が多いけど、元から連休などなく働き続けている可能性もあるよね…
SAKURA87@多摩丙丁督 @Sakura87_net 2019年4月29日
korekuutokooru1 銀行のシステムはデータ量が膨大だから西暦で管理するより元号イニシャルと年数二桁で管理したら、なんと1文字分も削減できて100万件でフロッピーディスク3分の1枚分も余裕ができるから。古いシステムとの互換性を保っているところは和暦管理ということは多い。
Alpha with CUB&GSR @2525_Alpha 2019年4月29日
2mocccck 今は「ローソン銀行」で、立派に銀行業のATMなのです。
Metallis(PIU筐体買取中) @c7R1S0tU 2019年4月29日
sakuuuuuuune コンピュータは英語処理が基本なので、日本語の処理は常に問題が付きまといます。たとえばperlの処理系でShift_JISを使っていると文字によってはそのままでは正しく表現できない場合があります。発表後にはUnicodeの文字コード問題も(レアケースにしろ)提唱されました。これらすべてを処理系ごとの事情も考慮して事前に対応することは不可能だと思います。https://togetter.com/li/1333809
窓辺 @madopen 2019年4月29日
これマジであかんやつや。っていう定型文言ってネタにしてる場合じゃないほどヤバイ
@howamo 2019年4月29日
元号・・・ヨシ!👈😺
あごにー @Agony_01 2019年4月29日
金融系でこれはヤバいやつぞ・・・
エビゾメ @ABzome 2019年4月29日
この数字のとおり取引されたら通帳には印字されなかったりするんじゃないですかねこれ……大丈夫なのかな……
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
korekuutokooru1 内部計算を和暦にする意味は、勘定系のメインフレームって昭和に作られたものが多い、昔はいまほどPCのパワーがないのでプログラムを書く際に1バイトでも要領を削減する必要があって、西暦なら4バイト使うのが和暦だと2バイトないし3バイトで済むので和暦使ってたのよ
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
juEsJsX5eMoEbxx 改修しようにも平成不況で金はないし、変えたところで儲けにもならない、その上変えてバグ出せば金融庁から怒られるし、物によっては凄まじい損害が出るっていうのでズルズル昔のプログラム使用し続けてきたのよ
サスガ @tigercaffe 2019年4月29日
はい、嘘松ぅうううううううううううう!!嘘松ぅうううううううううううううううううううううううううううううううううううう!!!(現実逃避)
すいか @pear00234 2019年4月29日
[c6233223] そもそもとして和暦がベースでシステムが作られたからでしょうな。昨日今日作ったようなシステムじゃないわけだし。
ゆーき @yuki073 2019年4月29日
juEsJsX5eMoEbxx 一応西暦をBCDで表記すれば2バイトになるんだけど、和暦でも容量は同じだから出力に合わせて和暦を選んだだけじゃないかなと。
じぇみに @jeminilog 2019年4月29日
バグなんて動かさないと出ないもんだ(悟った表情)
じぇみに @jeminilog 2019年4月29日
事前準備できるならバグなんて出ないでしょなんて明朗に言えるプログラマーは相当に業務歴が短いと思うわ
Metallis(PIU筐体買取中) @c7R1S0tU 2019年4月29日
yuki073 その場合和暦だと1バイトじゃないですか?
すいか @pear00234 2019年4月29日
yuki073 そもそもとして、「一番の基本になるシステムが作られた時代は、和暦を基本に日本社会全体が動いていたから、和暦を使うのが当たり前で最も合理的だった」だと思いますけどね。政令から省令からから庶民の社会生活の基本が和暦であって、西暦ベースが広まったのなんてここ25年ぐらいじゃない?
SAKURA87@多摩丙丁督 @Sakura87_net 2019年4月29日
おちゃめなプログラマ「どうせ平成しか扱わないんだし、とりあえず年に1988足しておくか。」
Metallis(PIU筐体買取中) @c7R1S0tU 2019年4月29日
今回こういうことがあったってことは、次は昭和100年となる2025年にまた何か起きるかもしれないですね
ゆきの @yukino112 2019年4月29日
北陸銀行のお知らせ。日付ないけどいつ発見されたのか? https://www.hokugin.co.jp/info/important/archives/personal/2019/1625.html
木場貴志 @cobatacashi 2019年4月29日
なんで内部処理が元号ベースになってんだよ……。
intiki @intiki 2019年4月29日
和暦西暦変換でのトラブルとか、いざ始まったら結構他の所でもありそうな感じだがねぇ。システム屋さん本当にお疲れ様です
intiki @intiki 2019年4月29日
つーか01年で1901年とか吐き始めるクソシステムはまだか
mikumiku_aloha @mikumiku_aloha 2019年4月29日
yukino112 やらかしたの北陸銀行だったんですね。
月戌🐔🐍🐷㌠ @_moondoggie 2019年4月29日
エンドレス・ヘイセイの始まりである(SEさん体壊さない程度にちょう頑張って)
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
yukino112 よかった表記だけの問題か、とりあえずよかった
月戌🐔🐍🐷㌠ @_moondoggie 2019年4月29日
.oO(てか①表記上の問題である②内部の元号処理を外出しのときに西暦変換してる③ほくぎんサーバレベルの話臭いっつーことは昔から帳票保存的に和暦でやってたのをATM対応時に無理くり変換モジュールひっつけたとかなんかしら)
mikumiku_aloha @mikumiku_aloha 2019年4月29日
marumasa58 やらかしたのは振り込み先の北陸銀行だとすると、ローソンのATMの表示の直前でのバグでは無いことが判明ですか
NK-BOT @garland4904 2019年4月29日
Dメールならぬ、Dキャッシュ!?
のー @namcat 2019年4月29日
振込実行した結果令和元年5月7日に振り込まれなかった場合「確認しなかったユーザーが悪い」として銀行は法的に対抗できるだろうか? (平成元年に振り込まれた事実がないじゃないかと反論されて負けるだろうけど)
nekosencho @Neko_Sencho 2019年4月29日
真面目に受け取ったら、過去に送金されてから今までの利息もつくしな。
SIROWENLI @sirowenli 2019年4月29日
帳票の制約で、『令和』の印字が5月まで未来日でも印字できなくて、元年フラグだけ立てたのが原因な気がする。
yat @yat_tay_yat 2019年4月29日
過去に振り込むことでバブル崩壊を防ぐ小説書けそう
シンゴ @signa_11 2019年4月29日
北陸銀行でググれば分かるけど、共同システムを使ってて他に4銀行使ってる。で、このシステム、母体となるシステムがあって10数銀行が使ってる。さらにそれを母体とするシステムが複数あって(ry。もし、母体バグなら…。((((;゚Д゚))))
Wolkenbruch729 @wolkenbruch729 2019年4月29日
内部的には西暦を用い、表示に元号が必要な場合の処理は専用のものをひとつ作って元号を表示させる時のみそれを呼び出せばいいという素人の素朴な提案はプロから死ぬほど叩かれるが、結局こういうことが起きて青くなってるじゃないか。
かつま大佐(永遠の10歳📛) @kamiomutsu 2019年4月29日
何となく「2000年問題」ってこういうイメージだったなあって思った。
Ichigo Mayo @15my 2019年4月29日
計算と表示はおそらく合ってて、途中で和暦になってて令和対応と令和未対応の箇所を通っていると思われるあたり利用者が思うのと比べて相当複雑なシステムになってるっぽいな...
想 詩拓@文芸サークル『文机』 @sou_sitaku 2019年4月29日
こういう目に見えるバグって、どういう理屈でそのバグが出るのか、考えるのがちょっと楽しい。しかし、腑に落ちないな。多分、このシステムは和暦が基本で、西暦には和暦から変換していたんですね。ただ平成元年が31年4月30日で終了するため、そこで一度カウントアップせず、それ以降の日付については、【最新の元号元年】にカウントアップするようになってた。でも【最新の元号元年】に令和がセットできていなかったため、【最新の元号元年】は【平成元年(=1989年)】になってしまったということですかね。
Ichigo Mayo @15my 2019年4月29日
令和対応モジュールしか通ってなければ正常に出るのはもちろんだけど、令和未対応モジュールしか通ってなければ31年のままなはずなわけで...
Shin Matsuda (syncbunny) @syncbunny 2019年4月29日
改元のスケジュール発表から相当時間あったから十分テストできたでしょうに。そんなやっつけ仕事で銀行業務処理してるの?
月戌🐔🐍🐷㌠ @_moondoggie 2019年4月29日
.oO(何となく”元号”そのものの定義と”個別元号”の定義でわやがあってそこの結合テストのパターン不足という気がしてきた…)
さむわんわんわん @some_one11 2019年4月29日
元号早めに発表してればと言ってる方結構いるけど、これって問題すら把握してなかった可能性あるんじゃないの?
じ〜げん〜 @jigen357mgnm 2019年4月29日
30年分の金利が10日でもらえるなら、こんな有難い話はないぞw 目一杯借金してでも口座に突っ込みたいww
mikumiku_aloha @mikumiku_aloha 2019年4月29日
スケジュールが厳しすぎると検査不合格にしずらい圧力がかかる。リハーサル、本番に予備日があれば、本番で管理上の不備が見つかったけど実働には影響なかったみたいな検査結果になったときにダメ出しして予備日に日程ずらすとか出来るのだけど、予備日ないとムズカシイ判断を強いられる。
机ひとつ @msyk_hmns 2019年4月29日
「西暦」→「元号(令和対応)」→「西暦(令和未対応)」という流れだよね。ATM端末の問い合わせに元号で返してくる仕様が今も生きている(使わざるを得ない)という事情がとても興味深い。
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
sou_sitaku 単純に元年の文字が含まれてたら1988をアウトプットするみたいな糞モジュールかませたのかも
mikumiku_aloha @mikumiku_aloha 2019年4月29日
"銀行間 振込 フォーマット"で検索して出てくる『全銀協規定フォーマットとは、全国銀行協会連合会がデータ伝送を行うために定めたフォーマットです。当組合法人インターネットバンキング総合・給与・賞与振込で、外部データから振込データを取込む際のフォーマットとなります。』の日付のところには月と日だけで年がない。 http://www.hyogokenshin.co.jp/wp-content/uploads/format1.pdf
えんぞ @jinsei_febreze 2019年4月29日
syncbunny 一度もテストをしたことのない馬鹿は黙ってろ
にっちー@改名しました @HjAkeru 2019年4月29日
改元の当日の表示がどうなるかなんて真っ先にテストするはずの箇所をやってないあたり相当切羽詰まってたんだろうな
机ひとつ @msyk_hmns 2019年4月29日
mikumiku_aloha 通信では複数年を跨ぐ事はありえないから年は不要、という事なのでしょうか。だとしたら、端末内部だけでの西暦元号の変換不具合、という事になりますね。
からす @pashikuru 2019年4月29日
システムテストも運用テストもやらなかった案件?そんなこと有り得るのか?いや起きてるけど、銀行が?
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
pashikuru UFJと三菱が合併するときは三菱側のシステムに寄せたから、UFJ側のシステムはそのままテストせず納品したよ
mikumiku_aloha @mikumiku_aloha 2019年4月29日
ローソンのATMで誤表示が発見され北陸銀行が不具合の報告をしていて『【お詫び】コンビニATM(イーネット・ローソン)における改元に伴う障害発生について』って事はの北陸銀行のATMは大丈夫だったと思われ、謎。
しわ(師走くらげ)@寝貯めしたい @shiwasu_hrpy 2019年4月29日
SANチェック失敗勢がちらほら居て草(生えない
からす @pashikuru 2019年4月29日
juEsJsX5eMoEbxx 生産管理の基幹系システムだと企業合併でシステム統合で修正入ってないところも何の影響出るかわからんから結合テスト以降の工程では全部流すのに、お金を管理する銀行のシステムが何ということ
からす @pashikuru 2019年4月29日
ローソンのATMのバグだとすると、どういう仕様なのか想像できんな。一回和暦にするサブルーチンがあったが、平成の終了日以降なのでバグって戻り値が平成開始日だったとか。とすると変換ルーチンのバグかテーブルの設定忘れかな。後者くさいが。
もくざい @mokuzai_tig 2019年4月29日
_Nekojarashi_ これがオキャクサマの普通の感想だよなぁ…胃が痛い
ゆーき @yuki073 2019年4月29日
c7R1S0tU 元号のイニシャル1文字+2桁想定です
Yeme @yer_meme 2019年4月29日
どういう仕様なんスかね……年を二桁で表すために和暦使ってたとかっスかね?で西暦に変換するまでに訳判らんことになったとかっスか?
F @hehe3000 2019年4月29日
なんでもいいけど元号表示はやっぱ悪い文化だわ…
mikumiku_aloha @mikumiku_aloha 2019年4月29日
pashikuru おそらく三菱銀行側にお任せになって、三菱銀行側が結合テストしたってことだと思います。 https://tech.nikkeibp.co.jp/it/free/NC/NEWS/20050218/156394/
想 詩拓@文芸サークル『文机』 @sou_sitaku 2019年4月29日
juEsJsX5eMoEbxx 流石に日付の元データが「元年」って文字列なわけがないので、日付の元データ(おそらくR01.05.07)→どこかのモジュールで「令和元年」に変換→表示システムで元年が含まれているため「平成元年」と判定→「1989年」をアウトプットみたいな流れですか。そんな馬鹿なと思いたいですが、それならテストに漏れたというのにも分かる気がします。
FOO @foomodel 2019年4月29日
「うちは大丈夫か?!」と休日なのに呼び出して、全プログラムのソースチェックをさせるシステム部のお偉いさんがいない事を祈るばかり。
PAKU♉ @PAKU 2019年4月29日
おなじほくほくフィナンシャルグループの北海道銀行にも同じ内容が出ています。 https://www.hokkaidobank.co.jp/news/campaign/detail.php?id=2181 勘定系共同化とかでもしてたのかしら?
@nyaccy 2019年4月29日
おわりのほうのお詫びの「正しく処理されます」で心底ほっとした
@nyaccy 2019年4月29日
でも過去の自分に送金できたら楽しいなぁ…あの頃の自分にお金があったらあれもこれもできたなぁ…とか
ぬめりけ@ガチで永遠となりかけてるよろず屋に幸あれ @pokute55 2019年4月29日
我が身が関係ないポジションにいる厨二なので、これは平成がループする前兆…?と思ってしまう
ぬめりけ@ガチで永遠となりかけてるよろず屋に幸あれ @pokute55 2019年4月29日
逆に考えるんだ、機械の方が正しいのだと…人が観測できない平成の繰り返しを、機械だけが正確に表示しているのだと…
gx9900 @GX9900GUMDAMX 2019年4月29日
PAKU 表示だけっぽいですな >お預かりいたしましたお振込みはご予約の指定日に正当に振り込まれます。
野獣後輩 @yaju5123 2019年4月29日
syncbunny お前金融のフロントオフィスで一度でも業務やってみろ。そんな考えだと吐くぞ
近藤 和宏 @kondoujp 2019年4月29日
全銀フォーマットだと YYMMDD (年は和暦) で「元号指定部がない」形だから、操作日が 310428、処理日が 010507 の振込電文を作り、それを元に画面情報を出してたが、その際「この年号の和暦がいつを指しているのか」を操作日ベース ("平成" 31 年) で決定していて、処理日の 01 が "平成" 1 年と出てしまった、とかかなぁ……。 このパターンだったら、電文の日付自体は適切だから 2019-05-07 処理になる筈。
アギト @murasame1198 2019年4月29日
タイムマシンのプロトタイプかもしれん…! まぁ表示だけみたいだし大事には至らないみたいか
野獣後輩 @yaju5123 2019年4月29日
金融系は法律やらコンプライアンスやらでガチガチに縛られて仕事しなきゃならんのに、顧客側がbiim兄貴並みにガバやらかすせいで死ぬのだ
カスタム兆人 @juEsJsX5eMoEbxx 2019年4月29日
pashikuru 今更だけど、UFJ側のシステムは捨てて三菱側を導入するから当時改修してたUFJのシステムはテスト無しで納品したのよ
zaizeno @zaizeno 2019年4月29日
mikumiku_aloha 全銀協規定フォーマットの日付部分がMMDDで年の指定が無いとすると、通信された日付も0507だけで、ATMの方で勝手にこれを01年05月07日と解釈しちゃったってことでしょうかねえ。(え? ということは、ATMは内部では元号で動いてるってこと⁇ だとしたら、5月1日以降の日付は全て1989年と解釈されちゃうバグ???)
ぷらずまわい @plaxma_y 2019年4月29日
105歳ぐらいの人宛に行政から保育園の案内が届いたの海外でありましたね
zaizeno @zaizeno 2019年4月29日
なんにしても、内部的に元号を使っているという仕様が不可解。なぜそんなことをしたのだろうか。和暦を使うにしても、どこぞのシステムでは内部的に神武皇紀を採用したそうで、それなら一応合理性があってわかるのだけれども... ( 少なくとも西暦2039年まではw)
mikumiku_aloha @mikumiku_aloha 2019年4月29日
zaizeno 2000年問題の時にどっちに統一するかで和暦の方に統一したとかあったら笑えるけど流石にそんな事は無いだろうし
近藤 和宏 @kondoujp 2019年4月29日
zaizeno 実際の内部向け操作上はきちんと年のデータを持っていても、銀行間連携用データのライフサイクル的に MMDD で十分な場合は年がないのは妥当ですね。 全銀フォーマットって形式とかによっては普通に年ありますし。(例えば明細参照系は YYMMDD https://www.aeonbank.co.jp/business/pdf/manual_other_02.pdf )
近藤 和宏 @kondoujp 2019年4月29日
全銀 EDI システム XML 形式の場合は年月日は西暦取り扱いなのだけど、当然の様に「全銀(データ)は“YYMMDD”(和暦)形式のため、“YYYY-MM-DD”形式に変換後……」とか書いてあるのがなんとも。和暦での操作が本当に大前提。
KAME_qwert @KAME_qwert 2019年4月29日
北海道銀行のアナウンス見る限りでは 1・振込予約は「2019/05/07」だね 2・和暦だと「令和1/05/07」だよ 3・でも「2019/04/30」までは「平成」で計算するよ 4・だから「1年」は「1989年」だよ 5・予約は「1989/05/07」でOK?  って事ではないかと
KAME_qwert @KAME_qwert 2019年4月29日
振込予約だから全銀ネットに電文は飛んでないよ(電文が飛ぶのは5月7日)。だから基幹系の「MEJAR」か「BeSTA」の問題かな。ATMは基幹系の吐き出した確認文字列ををそのまま表示してるだけだと思う。 なお、全銀の振り込みは「1年先の振り込みなんて出来ない(考えてない)」ので「月日」だけでも問題なし。
kartis56 @kartis56 2019年4月29日
さすがに対応早いな
KAME_qwert @KAME_qwert 2019年4月29日
近藤 和宏 @kondoujp 氏と被ったな (日付問題)
しむらさとし @shimurasatoshi 2019年4月29日
NHKでニュースにもなってますね。>コンビニATM 改元に伴う誤表記トラブル | NHKニュース https://www3.nhk.or.jp/news/html/20190429/k10011900621000.html
すいか @pear00234 2019年4月29日
wolkenbruch729 「今から作る」と「既存のものを改修する」では話が全然違うし、素人の思い付きが叩かれるのは今回問題なのは後者の側なのに前者の側のノリでいうからじゃないすかね。
すいか @pear00234 2019年4月29日
zaizeno 「そもそも、昔から日本は和暦でことを運ぶのがデフォルトだった」からでしょうな。法令やら地方自治体の書類手続きやら、もちろん銀行も民間企業もなにもかも。そういう時代に設計されて作られたシステムなのだから、和暦で扱うのが合理的だったんですよ。その上に各種の構築や修正がなされてるわけです。西暦ベースでことが運ぶのなんて、ここ20年とか25年ぐらいですよ。
Natsuki @Natsuki902 2019年4月29日
sige001621 おそらくですが、どこ宛でも「010507(令和1年5月7日、一例です)」と応答しているんではないでしょうか。 で、それをローソンATM側で西暦変換する際に、という。
きゃっつ(Kats)⊿11/17乃木坂大阪個別 @grayengineer 2019年4月29日
「表示だけの問題か」ってそりゃそうでしょ。内部の計算にわざわざ元号使わないですよね
お空キレイキレイ @747_bold 2019年4月29日
めっちゃ心臓にくる 処理直すの優先で表示まで手が回らなかったんだよねそうに違いない
mikumiku_aloha @mikumiku_aloha 2019年4月29日
[ ouminoumare 浜銀は4.26には分かっていたわけですね。神奈川県民からするとグッと話題が身近に感じられました。
uki @netgameneet 2019年4月29日
かなり高位の恐怖画像
すいか @pear00234 2019年4月29日
grayengineer どこまでを内部と言うのかによりますが、全銀フォーマットという、いわゆる「銀行間のあらゆるカネの移動に使われるデータの書式」が和暦前提なので、むしろ「内部計算の根幹は和暦」と言っていいんじゃないすかね。実際に外部記憶装置に書かれるデータがどうなってるかにもよりますが、例えば外部記憶装置には西暦のYYYMMDD、電文が和暦のYYMMDDと言ったときに、どちらを「本当の内部」と呼ぶかみたいな。
mikumiku_aloha @mikumiku_aloha 2019年4月29日
「表示だけ」と言い切れるのはATM側に問題があった時で、振り込みを受け付けた側の問題だとするとその経路に何の影響も無いかどうかは経路側の調査が無いと確定しないはず。
すいか @pear00234 2019年4月29日
mikumiku_aloha 北陸銀行のお知らせを読む限りだとその辺りの調査は既に終わってるんじゃないすか?
mikumiku_aloha @mikumiku_aloha 2019年4月29日
ここのサイトで地方銀行が使用しているシステムの一覧を見ると、 http://www.fina-sol.com/handbook/bank/core/core-regional NTTデータのMEJARって奴かな。
kartis56 @kartis56 2019年4月29日
wolkenbruch729 データベースに入ってる今までのデータを全部西暦に変換しないといけない
mikumiku_aloha @mikumiku_aloha 2019年4月29日
MEJARという共同センターを使っている銀行は、北海道、七十七、横浜、北陸、東日本銀行?、
mikumiku_aloha @mikumiku_aloha 2019年4月29日
pear00234 横浜が4/26には発表しているということは、少し時間があったはずなので一通り経路の調査が終わった上でと考えた方が良いですかね。
KAME_qwert @KAME_qwert 2019年4月29日
印象としては、ATMの確認画面表示用の日付の和暦→西暦変換に問題があったのではないかと
希望 @nozomi_crs 2019年4月29日
新しい情報も含めて考えると「2019/4/30までは和暦「31」→西暦「2019」に変換(+1988)」「2019/5/1からは和暦「01」→西暦「2019」に変換(+2018)」の2つの処理を実装。今現在の和暦の変換は正しく出来ているけど、振込日として令和の和暦「01」が出てきたけど4月だから前者の変換処理(+1988)を適用してしまったがために西暦「1989」になった。あたりが正解に近そう。
zaizeno @zaizeno 2019年4月29日
pear00234 「そもそも、昔から日本は和暦でことを運ぶのがデフォルトだったから」というのは、紙の上でそうだったのはわかりますが、コンピュータシステム上でまでそうだったのは驚きです。(改元がありますから)   私は銀行や役所や学校のシステムには疎いのですが、80年代にはコンピュータの世界では内部的には既に西暦が普通だったように記憶してましたもので。(技術計算や組み込みなどの世界限定ですが)
あずいち@私は肉とビールを愛す @lovely_fishes 2019年4月29日
tuoKb2XBrCPRjhV 星新一味があってこういうの好きだわ。 このまとめ自体は、システム屋としてぞっとする話だけど・・・。
すいか @pear00234 2019年4月29日
zaizeno 2000年問題で有名になりましたが、基本的にタイムスタンプは「1970年1月1日0時0分0秒からの通算秒数」(ほかにいくつか別バージョンはありますが)ですし、当時西暦使ってたのはぶっちゃけコンピュータシステムだけと言っていいです。「実世界が全て和暦で動いている以上、コンピュータシステムも和暦を基本に扱うよう設計する」ことは判断として極めて合理的だったと思いますよ。どこにも驚く要素はありません。
すいか @pear00234 2019年4月29日
pear00234 もちろん「当時としては合理的判断であった」ことと「結果的にその判断はハズレだった」ことは矛盾するものではありません。念のためここお間違えなきよう。
cocoon @cocoonP 2019年4月29日
pear00234 「西暦にすればいい」とドヤ顔で言ってる人が2038年問題についてどうコメントするか見てみたい(本質的にはエポックをどこにするかの問題だから西暦そのものの問題ではないけど)ですねw
cocoon @cocoonP 2019年4月29日
じゃあどうすればよかったのか、を考えるにUNIXTIMEがUNIXTIMEとUNIXDATEを分けて扱っていれば問題は生じなかったのかというと結局それは64bitのUNIXTIMEを使っているのと大差ない(むしろ使える空間は減る)ので悩ましい所ですなあ。
cocoon @cocoonP 2019年4月29日
結局「日時は文字列で扱う。いちいち変換関数を噛ます」のが普遍的に正解な気がしてきた。そう考えると全銀は悪い文明ではないのかもしれない。年号を使用していることによって変換関数を噛ませるのがほぼ強制になるから。
zaizeno @zaizeno 2019年4月29日
cocoonP 2038年問題は、元号を使ったからといって対処が有利になるわけでもないように思いますが....。(もちろん西暦を使っても同じでしょうが)
mikumiku_aloha @mikumiku_aloha 2019年4月29日
金融系は一般社会よりコンピューターの活用が早かったので、その分、(運用によっては)データーベースの中のレコードの1バイトが貴重という古い設計が残っている可能性があります。
nekora2520 @nekora2520 2019年4月29日
マスコミの皆さんが手ぐすね引いてお待ちかねなのに、何とショボい障害…。 最低でも送金ストップ一週間は欲しい。
Kei K @keix_k 2019年4月29日
そーいや、メガバンクM(旧F)の通帳が昨年のGWでやっと西暦表記になったっけな。
cocoon @cocoonP 2019年4月29日
zaizeno 「西暦にすればいい(ドヤァ」に対する批判なんですから、貴方のおっしゃっているコメントの通りで、それがすべてですよね。和暦が有利とかそういう話はしていませんよね。
Mill=O=Wisp @millowisp 2019年4月29日
うっかり30年分くらい利息つかないかなぁ
まさご叔父さん @masago53 2019年4月29日
金額がオーバーフローして5000兆円振り込まれたい
Husetsu @husetsu126 2019年4月29日
よりによってATMでやっちゃったか…というかまだこういう系の報告見てなかったな、見逃してただけか
すいか @pear00234 2019年4月29日
mikumiku_aloha リソース管理の問題よりも、「社会の問題をどのように計算機処理に設計実装すべきか」、もっというと「その時社会はどのように動いていたのか、人々はどのように日付を扱っていたのか」「計算機と社会の関係とはどのようなものであるべきか」という、そもそもの思想的な問題ですらあると思いますよ。社会全てが和暦で動いている中、「とあるタイミングからの秒数」で日付を管理している計算機が、社会の問題をどのように設計実装すべきか、という話です。
すいか @pear00234 2019年4月29日
cocoonP 「日時は文字列で扱う。いちいち変換関数を噛ます」だと、時差だのサマータイムだのうるう年だのがすげぇ面倒になるので(日本はともかく、欧米の日付時間表示の揺れの多さ具合とかかなり発狂もんですし)、結局のところは「Epochからの秒数」というのが「最も弊害が小さく負荷も小さく使いやすい」管理方法なのかもしれません。
なちゃ @nachakey 2019年4月29日
まじでわろえないよなあ… 下手したら他人事じゃなくなる人もいっぱい居るだろ… よく今時のシステムで何でまともに対応できないとか言う人いるけど、まあだいたいトラブルの原因は今時じゃない部分にあったりするわけさ。 大昔に動けばいい感覚で作られたヤバいソースもいっぱい現役で動いとるわなあ…
なちゃ @nachakey 2019年4月29日
相互影響が大きすぎて今更変更できない部分同士のつじつまを合わせるためにいろいろ解釈の仕様やらを改修するけど、そこに見落としパターンがあったりするとこういう事は起こるよね…
森のクマッチング(ぽっけ風) @peerchaky 2019年4月29日
(´・ω・`) この手のシステムは色々古いシステムが残りっぱなしで、有識者ももうおらんとかいるけど文書がないから細かい仕様がわからんとかもあるよ。 エンジニアが元号発表一月前は遅い!というのも、平成仕様になってた部分を変えるので影響範囲の確認だけで時間が掛かるのよね
anon@game @anon_game_ac 2019年4月29日
コメントみると、『あぁ、この人同業者だわ』って人と、『システム関わってるけど他業界の人だわ』って人と、『なんか憶測でそれっぽいこと言ってるわ』って人がよく分かるw
anon@game @anon_game_ac 2019年4月29日
KAME_qwert BeSTAの問題なら、BeSTAベースの他シス合わせて数十銀行で発生しそうなので、MEJAR側かも? でも、BeSTAベースの全共同システムは「うちは大丈夫なんだろうな?」と保守で調査出勤させられてるかもしれないね(苦笑)
cocoon @cocoonP 2019年4月29日
pear00234 今から置き換えられるなら128bitくらいにして0000/01/01-00:00:00.000をエポックにしたミリ秒単位にしたいですねw(マイクロ秒の方が嬉しい業界もあるのかしら)天文学やってる人たちはユリウス通日の起点がエポックのほうがいいのかな?
白山風露@ᘇΩᗢ @kazatsuyu 2019年4月29日
2000年問題が大したことなかったのは十分な準備期間があったからだということがよく分かる事案だ
きゃっつ(Kats)⊿11/17乃木坂大阪個別 @grayengineer 2019年4月29日
pear00234 いや「期間計算」の話です。異なる元号間で期間を計算するには、いったん西暦か、そうでなくても元号に依存しない紀年体系に変換してからでないと計算できないわけですから。
すいか @pear00234 2019年4月29日
grayengineer そもそもこの問題に「期間」とか関係なくないですか、 少なくともkondoujp 氏の推測が正しいなら(実際これがビンゴだと僕も思いますが)。「〇年△月×日に受付」「●年▲月■日に実行」&その他もろもろのデータにおいて、その年月日が和暦YYMMDDだから、扱う箇所によっては対応不足だとこうなるって話なんですから。
tibigame @tibigame 2019年4月29日
grayengineer 和暦だけでも可能です。その元号の日付入れたら末尾日および先頭日までの期間を返す関数と、元号の順番のリストがあればよい。
すいか @pear00234 2019年4月29日
cocoonP 西暦に0年は存在しない(AD1年の前はBC1年)なのでそれだとだめです(マジで それはさておき、マイクロ秒単位が欲しがられる話になると、ナノもいやピコまでだとか言い出される可能性が高いので、いっそのこと秒で済ませましょうw
きゃっつ(Kats)⊿11/17乃木坂大阪個別 @grayengineer 2019年4月29日
pear00234 この件は表示の問題だからですよ。表示ではなく実際に期間を計算している部分で元号を使うことによる不具合があるなら困るけど、そんなことはないから、表示では問題になっても、期間計算で問題になることはないでしょ、っていう指摘です。話の筋が見えにくいのかもしれませんが
きゃっつ(Kats)⊿11/17乃木坂大阪個別 @grayengineer 2019年4月29日
tibigame 可能であることはわかりますが、実際にそれを採用しているところがどの程度あるかはまた別問題です。少なくともその方法はリスクが多すぎて、あまりおすすめできないです
tibigame @tibigame 2019年4月29日
複数の時間の進み方があることに対応できないと地球の時刻と同期してられっかと時計戦争が起こります。
すいか @pear00234 2019年4月29日
grayengineer 大元の根っこになるデータが和暦前提、しかも「一度変換したデータが使いまわされる」じゃなく、「独立に各所で西暦に変換させる」ように作られてるような気がする(これは僕のカンですが)ので、「それは結局のところ内部は和暦ってのに等しいような」ってのが僕の考え方なんですよね。
ばしにぃ @hiro_orso_viola 2019年4月29日
和暦変換なんてJavaかOracleかフロント側に任せとけばいいのに…
夏越丸@ねんくり引き取り先募集 @nagoshimaru 2019年4月29日
早く発表したからってなくなってた問題なの?これ。
近藤 和宏 @kondoujp 2019年4月29日
cocoonP 本来的に言うと、"epoch time" って「新しい紀元」とかの意味もあるので、1970-01-01 みたいな半端な年ではなく 1900-01-01 とかを起点にした方がいいって話はあるのですが、残念なことに 32bit int だと秒単位でも 100 年すら表現できないのですよね。 どうせならビッグバンからのミリ秒単位での…… (128bit で足りるのかソレ)
近藤 和宏 @kondoujp 2019年4月29日
cocoonP あと一点言うと、(多分指が滑ったとかだと思いますが) BC も AD も「0 年は存在しない」ので、AD 0001-01-01 の前日は、BC 1 年の大晦日です……。
近藤 和宏 @kondoujp 2019年4月29日
hiro_orso_viola WebLogic だけでも今月 2 回ほど脆弱性更新が出てる Oracle に任せるって、それこそ「ご神託にお任せしたらいい」っていうネタかな……。 今回の不具合の原因って、「全銀フォーマット的に元号を表現する情報がない」のが原因としか思えないのですが、Oracle や Java に任せたらクリアされる要素ってあるんですか?
近藤 和宏 @kondoujp 2019年4月29日
本気で頭痛い点って、メガバンクは「1 日の取引量がマジ半端ない」という話で、「きちんと記録を残す」という当たり前のことをやると、元号分を 1 バイト増やすと、平均して 1 日 1 億件の取引が発生すると 1 年分で約 34GB 程度増えるんですよね。フォーマット上 1 バイト増やした結果で、それ。
近藤 和宏 @kondoujp 2019年4月29日
そして、全銀フォーマットの根本が制定された年代を考えたら、ある意味「2000 年問題引っかからないように設計してたのは GJ」という評価になるかなぁ、というところはある。ぶっちゃけ「西暦であったとしても、YY だと 00 って、何年を表現してるの」が出るので、結局和暦でも基本的に差はない。あと、閏年マジクソ。 4/100/400 を知らない閏年チェックコードとかいっぱい見たよ。
近藤 和宏 @kondoujp 2019年4月29日
grayengineer 根本的な話に言うと、「銀行間取引は和暦で行うので、和暦ベースの日付構造体を作って利用するのはリーズナブル」「UNIX TIME も Windows 高精度時間も "西暦" 関係ない (基点が AD 1-1-1 とかではない)」「銀行間取引上、サーバーからの応答が和暦なので、その応答をベースに組むのは理解できる」ですかね。 どっちかっつーと、「ローソンの ATM を使用した」状況において、「ローソン銀行ではなく北陸銀行からアナウンスが出てる」の方が、ちょっと謎感が。
片山 和紀 @night_wizard 2019年4月30日
kondoujp 100年に一度閏年じゃないのは知ってるけど、2000年は400年に一度の閏年だし、2100年までこんなコード使わないよね。という思想で敢えて4年に一度の閏年だけのロジックにしている例もあったりしそう。(^_^;)
愚民Artane.🦀@水に落ちた犬は打て。 @Artanejp 2019年4月30日
chigintech 横浜銀行に口座があるので…金曜に全額引き出しておいて正解でした(´・ω・`)はじめまして(´・ω・`)
愚民Artane.🦀@水に落ちた犬は打て。 @Artanejp 2019年4月30日
kondoujp 和暦をベースにしてる時点で、全銀フォーマットがダメなのでは…(´・ω・`)後、今どきは取引記録を逐次圧縮しないものなんでしょうかね。
とんぬらa.k.a.とんちゃん @t_matsu 2019年4月30日
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/04881/ ・24時間365日いつでも即時振込ができる全国銀行協会のサービス「モアタイム」に参加していないみずほ銀行など宛てに振り込みをした際に誤表記が発生 ・3行とも「MEJAR」を導入しているがトラブルはMEJAR以外の周辺システムで発生した模様 ・周辺システムはNTTデータ以外のIT企業が開発 さてどこがやらかした……
茗荷昇紘 @masilite 2019年4月30日
役所以外は和暦止めれば済んだ話でしょ。新元号発表まで待ってたらスケジュールとか間に合わなくなるのは目に見えてたのだから、天皇譲位の話が出た時点で元号依存を止めて西暦ベースに変えれば済んだ話。
茗荷昇紘 @masilite 2019年4月30日
もちろん、これは技術屋のせいではなく、システム発注元の責任だが。
脳内がエロで埋まっている白痴のネトウヨ @dokuman3 2019年4月30日
まあ、原因とかテストで漏れた理由とか対策とか、外部から推測だけでごちゃごちゃ言ってもなぁとは思うよ。
monolith@フォロー外から失礼します @se_monolith 2019年4月30日
令和対応改修なんて一瞬だろ、ブサヨ系システム屋が嘘ついてんだろ、って言ってる連中は、juEsJsX5eMoEbxxjuEsJsX5eMoEbxx の事情を知らないか、知らないことにしてんだろうな
とまとプリン @hirobumi_mmo 2019年4月30日
古から存在するキメラの一部だけそう都合よく切除出来るのならSEは苦労しないよ
ばしにぃ @hiro_orso_viola 2019年4月30日
実際メガバンクの基幹系でOracleやWebLogic使ってるものは普通にあるけどね…それこそ昔から。むしろ和暦が残ってるメインフレームとか、どっちかって言うと金融じゃなくて保険・生保系のほうが余程多い気がするんだが…。
anon@game @anon_game_ac 2019年4月30日
juEsJsX5eMoEbxx 4/27に振込予約しても、5/6に予約しても、振込日は5/7ですから、5/6までに対応して、それまでの取引データ補正まで完了すれば、「間違いは表示だけだった」ことにできますがね (;¬_¬) あ、私、同業者ですが、当事者ではないので真実は知らないですw
cocoon @cocoonP 2019年4月30日
pear00234 ああ……なんでも0から数えるこの業界によくある癖が……w ミリ秒UNIXTIMEはすでに一部では使われてたりするんですよねえ。
横えび @yokoebi 2019年4月30日
😆😊こ、これは笑って済ます人と凍りついてしまう人が多数?!
Wolkenbruch729 @wolkenbruch729 2019年5月1日
wolkenbruch729 今動いているプログラムは平成への改元を見てから作られたか、その前に作られ実際に改元を乗り越えてきたもの。 そもそも、改元があるということ自体は今のようなコンピュータができる前からわかっていた。 なぜ改元に対応していないのか。
anon@game @anon_game_ac 2019年5月1日
wolkenbruch729 まず、平成改元時に次回以降の改元も考慮した対応したはずという先入観を捨てましょう(笑)銀行は利益を生まない箇所には低コストしか使いません。当然その場しのぎです。平成時代に始まった共同システムも、中身は昭和時代のどこかの銀行が使ってたシステムのリプレースと言っても過言ではありません。昭和100年や2050年対応要りますよ (^_^;)
脳内がエロで埋まっている白痴のネトウヨ @dokuman3 2019年5月1日
yokoebi 笑って許して上げてほしい。ここまで大きい年数のズレなら信じちゃう人とかもいないでしょ?
ばしにぃ @hiro_orso_viola 2019年5月1日
平成改元時はある意味急遽だったのであんまり参考にはならないとも思うけどね。今回は少なくとも年単位で前から想定出来てたし、これまでの老朽化対応でやれてないんだとしたらエンドユーザが見落としてるわけで。 いずれにしても単純に言えばテストの不足。
アリ〜 @Rn3oAxnzuRvPt9l 2019年5月1日
お振り込みさせて頂こうと二回、試みましたがムリでした。今日厳粛な祝祭日で御座います。
RAIYA@提督 @RAIYASB 2019年5月1日
ihyoro 以前金融システムで働いてたけど 四半期(1月4月7月10月)末は担当SEはホテル住まいでしたよ まぁ運用担当の自分は24365だったのでGWなんて関係なかったがね・・・
亀亀たとる @tatorukk 2019年5月1日
if 日付=2019年5月以降 then 元号="令和" ならこんなバグは起きないだろ。
RAIYA@提督 @RAIYASB 2019年5月2日
tatorukk そのコードをCOBOL・PL/I・Java各種・Cシリーズ各種・ドットネット各種で記述しなさい。 また、連携システムとの調整を密に行い、トラブルが起きないように留意して作成すること。  これが実情だけど、正直やりたくねーわ
NiKe @fnord_jp 2019年5月2日
まあ、振り込み処理自体は正しく行われているという発表を信じるなら、今回の誤表示はエンドユーザーに見えてしまって目立つけれど、実際に発生した不具合はマイナーでさして危険なものではなかったんじゃないでしょうか。システム改修もテストも概ねきちんと行われていたのでは?
ろぼたま。 @Robo_Pitcher 2019年5月2日
金額計算用に密かに使われている昭和年度COBOLプログラムが最悪の場合あと6年後に炸裂するのか…
脳内がエロで埋まっている白痴のネトウヨ @dokuman3 2019年5月2日
tatorukk まあ、判定の日付に振込日じゃなくて処理してる今の日付を使っちゃったりね。
堀石 廉 (石華工匠) @Holyithylene 2019年5月2日
これ、平成元年の改修の時に入れ込んだ問題(仕様)が30年越しの今になって爆発したとかじゃないよな……
mmsaito @mmsaito1987 2019年5月2日
元号コードがフォーマット上にない(追加できない)ということが問題なのね。それではどう頑張っても慎重にアドホックな対応でしのぐしかない
zwanzigst @zwanzigst 2019年5月3日
携帯キャリアに登録してる生年月日がいつのまにか和暦xx年から19xx年に化けてたんだけど人力の変換作業がどっかに入ったのかシステム上のミスかは気になるところだな。
S.O. @so_rei 2019年5月4日
SEとしては和暦で処理するようなシステムなんかぜってぇ触りたくないのが本音です
妹之山正雄@デレ名古屋両日参戦 @masawoImonoyama 2019年5月5日
おそらく内部的には和暦でデータ持ってて、1=明治,18680101、2=大正,19120730、3=昭和,19261225、4=平成,19890107となってるところにマスタ側には「5=令和,20190501」ってマスタデータを追加して、「元号5、年数1、月数5、日数7」ってデータを持たせたんだろうけど、表示側にこのマスタデータが無くて「元号5?5はないからその前の4で表示!」って動いちゃったんだろうなぁ・・・関係者の地獄が終わってますように( ̄^ ̄)ゞ
あごにー @Agony_01 2019年5月5日
というか、しばらくは平成のまま運用でよかったのではと思わんでもない・・・ お上からしばらく混合になってもいいよって話もあったはずだし。 テスト終わったところだけリリースしてくれればええんや。
ログインして広告を非表示にする
ログインして広告を非表示にする