【悲報】ローソンATMが平成元年に戻るバグ発動 [192334901]
■ このスレッドは過去ログ倉庫に格納されています
改元問題やばそうだな色々と
ある程度の現金降ろしておいて正解だったわ
2019/5/1 令和
の設定をしてないとこうなる
この頃に戻ってもう一度日本経済やり直せたらな・・・
これ元銀行システムの中で元号使ってんのか?
元システムから1年渡されてローソン銀行側で対応してなかったってのが一番ありそうだけどもどっちもダメじゃねーか
なんで西暦にしないの
元号は形式的に残すだけでいいだろ
これはわろうてられるん?
行方不明なったりしそうで怖いわ
1989に困窮していた俺に金を振り込んでくれたのは未来の俺だったのか
貧しかったあの頃の自分に課金できる神アイテムがローソンに設置!?
バブルを謳歌できなかったオジサンオバサンが殺到しているという
過去の自分に振り込めてメッセージ欄にYahooを買え
「内部処理は西暦だから」で実機使った動作確認してなかったパターンだろな
担当会社は緊急対策会議の招集せんと
ピーカブ無かったことにするのやめろ
てか、あれは何がダメだったのか?
どうすれば良かったのか?
金融系土方ちゃんいつも荒れてない?
ここ無能しかいないのか
https://www.hokugin.co.jp/info/important/archives/personal/2019/1625.html
【お詫び】コンビニATM(イーネット・ローソン)における改元に伴う障害発生について
このたび、コンビニエンスストア内のATMにおきまして、お振込みおよびクイックマンのお借入れ・ご返済をご利用されたATM画面とご利用明細に、一部表記の誤りがあったことを深くお詫び申し上げるとともに、ここに訂正させていただきます。
お振込予定日 クイックマン次回返済期日
誤→1989-05-07 誤→1989-**-**
正→2019-05-07 正→2019-**-**
**は正しい日付
なお、お取引は上記の正しい日付で手続されます。 >>43
天才だな
通帳にそう記録されるなら30年分の利息出るな 北陸銀行とやらのシステムが和暦管理なんかな
和暦→西暦変換を1988+nn年でやってるんだろう
恐らくベースの1988って値を5/1に2018にするつもりが、今回みたいに元号跨ぎを考慮してなかった結果こうなってるみたいな
想像だけど
和暦をベースにして西暦に換算してたんだな
こんな回りくどいシステム組んだの誰だよ
wwwwwwwwwwwwwwwwwwwwwwwwwwww
タイムマシーン
クイックマンググったらカードローンじゃん
ダッサw
平成元年5/1現在の口座残高値へ
一斉にロールバックしたら笑うが
ちょっと振り込んでくるわ。もしかしたらワンチャンあるかも
天皇が即死んでまた改元になると殆どのシステムが破綻するやろなぁ
銀行システムは元号
預金通帳みりゃわかる。元号で管理してるんだもの。
それを容量不足の時にネット規格では西暦にしてたが、最新式は元号に出来るようになったので、銀行は元号入力にしたんだけど、古いコンビニATMだとソフトが西暦になってて銀行の元号規格を西暦に変えて出すようにしてるのでこうなる
ようするに世界のコンビニATMの標準取ろうとしたり西暦にしたのが悪い
>>23
さすがに金を扱うシステム内じゃ元号なんか使ってないだろう
画面表示系の日付データの受け渡しのどっかで一旦元号年になって狂ってるんじゃないかと
もう年表示は徹頭徹尾西暦にすりゃいいんだよな
元号死ね >>20
平成31年→令和元年 マイナス30年にして元号を変える
西暦もそれ当ててしまった だから元号なんてやめればいいのに
つうか強制じゃないんだから民間ではわざわざ使うなよ
二つの和らぎの時代の狭間だからね
この三十年は夢だったのさ
>>84
どうしても元号をやりたいなら
30年ごとの変更固定にして
最低でも2年前から次の元号を発表しとかんといかんな
数人だけで考えてバカみたいに秘密にする意味がよくわからんわ 表示だけ問題だから実際は問題ないだろうけどひでーなw
>>43
>>53
わりと冗談じゃなくヤバそうだな…😥 システム日から振込日計算するのを
和暦計算の処理に入って
平成の終了日過ぎてたから次の開始年見ようとしたら存在しなかったからとりあえず平成の開始年見たとかか
センスなさすぎだろ作ったやつ
ケンモメンがニートで預貯金管理してないの分かるスレだなw
無職で消費しかしないんだから元号がどうのと心配しなくていいのに何故か必死になる
北陸銀行のシステムがやらかしたっぽいな
単純に西暦から変換テーブル比較にすればいいのになんで引き算とかで調整しようとするかね
>>96
コレは内部処理されてるで
激ヤバだから、手書きで修正かまして時間稼ぎするけど 社内で使ってるソフトも新元号対応アップデート間に合わないってお知らせ来てたし今月中に現金下ろしとこうかな
>>99 >>52 のお詫び文によると利用明細書もダメっぽい 金融でナゼこんなことになるんだ・・・学生のプログラム大会じゃないのか(´・ω・`)
残高が学生の頃の1500円とかに戻されたりするかもしれないから、LAWSONには触ってはいけないな
>>115
てことは取引テーブルも間違ってるかもか
深刻だな >>60
たとえバグでも知らんぷりしても取ったら逮捕トラップやで >>52
表記だけ間違えてるっぽいから取引データは正しいんだな
それにしてもアホやな どうしたらこんなクソプログラム組めるわけ?
天皇が寿限無だとでも思ってたの?
>>107
メガバンクに勤めてた親に聞いたが銀行内部処理は元号だから西暦関係ない
システムは西暦だけど、内部処理でミスはないので金利払われるとか100%ない 西暦にすればいいのに
和暦使う事によるメリットってシステム屋が儲かるぐらいしかないだろ
犯罪者はこれで儲ける方法を思いついちゃうんだろうな
>>71
言われればたしかにUFJは先週まで元号だったから
休み明けは年のとこが1になってんだろうな
みずほは年明けて数日たってから元号→西暦に変えてたが
中途半端な日に変えんなよって思った >>132
銀行の社内文書は全部和暦だよ
西暦で出すと突き返される >>127
表記だけって発表してる可能性あるよ
実際の振込み日の記録も過去日になってたりしてソートで振り込まれた日付で出てこないとかの可能性はある なんで北陸銀行だけで発生して同じパッケージ使ってる他の銀行では発生しないの?
振込ごときをカスタマイズしてるんか?
教えて賢モメン
>>132
和暦を西暦に変えていたんだね
なんでこんな馬鹿なシステム組んだんだろ >>145
日本の勘定系ソフトでパッケージなんて使ってんの? きたあああああwwwwww
これで利子計算wwwwww
のりこめーっっっっw
7日までまだ一週間以上あるやん
奴隷IT土方なら余裕だろ
こんなゴミシステムつくったのどこかなー?っっっっっw
ジャアアアアアアアアアップwwwwww
>>20
システムがなぜか和暦で動いているんだろうな
未来日の和暦1年→西暦変換がまだ改元していないから平成1年→西暦1989年に変換されたのだろう >>142
社畜に緊急招集かかって手作業で修正すんのかな 同じようなケースの令和ショックはもっと来るだろうなぁ
元号切り替え前後で引き出せばジャックポットチャンスあるで
結局政治的権力皆無の天皇なのに
二重権威だなんだとかぬかしてた自民党が悪いんだろ
禅譲が決まったらさっさと元号決めて発表すれば良かったんだよ
2000年問題で起こるはずだった問題ってこんな感じだったのかな
自分の口座に振り込めば30年分の利子が付いてそれを引き出してまた振り込めば大金持ちになるんじゃね
>>166
あれ数年前にすでに起きてたってよ
部品注文で足の長いものとかで納期が1900年とか表示されてたケースあったらしい 繰上げのタイミングでバグったら数字のカウントだけ1になるのかな
振り込み日がおかしいデータになりそうだな
引き落としもできなく阿鼻叫喚
俺今はグローバルなアプリケーションしか担当してないから元号とか関係ないわ
頑張ってね
>>169
そして連休後に席がなくなるんですね知ってます インフラ系IT土方だけど金融には二度と戻りたくない
あんなの根っからのドマゾじゃなきゃ心か体のどっちかぶっ壊して早期リタイアだ
5月1日にではなく、やはりまたぐところで出るんだな。
過去の特定口座に金を振り込む事で現在の状況が変わっていく
っていうなろう書いていいぞ
月末までに対応できてないところはさっさと営業使って謝罪行脚させときゃいいのに何とかなるなるで連休入ったところからボロでまくると思うよ
::::::::::::::::::::::::::::::/ ̄\:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::| ┌ |:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::/\:::::::::::\_/:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::/\:::::::::::::::::::::::
::::::::/└/:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| └ |:::::::::::::::::::::::::::::
::::::::\/::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::\__|::::::::::::::::::::::::::
髪のあるころへ戻るんだ
彡 ⌒ ミ
|.| /(・ω・` ) //| /|
U_¶⊆¶⊆_ )_ / ̄|//./
./┌────┐| /'`) ././
/( / ≡≡≡ .//(__/././
| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|/
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
まだまだ、これからだな
5月1日を迎えて、どれだけのバグが出てるか?
元号なんて非合理的な仕組みを使ってるツケだな
>>186
これは対応したけどそれがミスってるから起きた問題でしょ 西暦の下2桁から無理矢理元号を生成する
自作ルーチンを使っていたんだろうな
30年前と金の価値が変わってないのが悲しいところだな
オラッ社畜SE仕事だ!
旅行中?今すぐ帰ってこい!
そもそも元号変わるってわかりきってるのにサプライズ感出そうとして1ヶ月前発表とかにするから・・・
>>198
これはどっちかっていうとシステムの根本の作りとかの方がネックだから
元号の文字列がどうなるかとかはあまり関係がない >>201
期間が短いからテストも雑になったんだと思うよ >>205
動作テスト自体は元号が明らかにならなくても出来ると思うんだけど 大雑把に考えてこれだけの対処が必要になるんだけど
原因調査→修正箇所調査→修正方法調査→影響範囲調査→PG修正→テスト環境で動作確認→本番環境へリリース
各工程で詳細決める会議も当然やるから、どう考えても連休中に終わると思えんわ・・・
>>207
そりゃできるけどやらないでしょ
余計な費用がかかるしまとめてやる 西暦でバグる意味がわからん
内部でいったん和暦に直してるのか?
意味あるんかそれ?
こういうのってさ
コンピュータの日付を変えてシミュレーション出来ないの?
今日は令和元日(2019/5/1)と設定して
これが日本経済崩壊の始まりだと今はまだ誰も知る由もなかった・・・
株価なんて、今はAIが動かしてるだけ
不祥事で上がるも下がるも、AI次第だし。
>>213
システムの設計自体がおかしいから、期間なんて関係ない >>166
しも二桁システムでは四桁でバグる
つーことで
メモリー増やして4バイト対応に
それで4バイト可能なら2バイト文字も二文字まで可能じゃん
で、テンコロ忖度ジャップ邦銀は和暦にシステム変え
で
和暦→西暦下二桁→西暦四桁→和暦
をやっていたら参照すべきテーブルがワケワカメ >>218
もともとダメだったとして今回の元号対応のテストで気付ける話だとは思うよ >>182
官公庁のクソバカ共が未だに和暦使ってるから仕方ない
奴らに提出が義務付けられてる公文書は全て和暦表記だから民間が使うシステムにも和暦変換処理を残さざるを得ない >>205
そもそもこんなのは開発当初にテストしておくべきこと こういう問題があるから和暦いらね
もっというなら天皇いらねみたいな考えが生まれるんだよな
アメリカのせいニダ
本当に1989年の過去に金を振り込めたとして
アメリカなら貨幣価値が200%
中国なら数十倍になるけど
日本では特に特もしないのが悲しいな
>>220
銀行やATM関係は元号を排除しよう
とかって動きはなかったわけ? >>229
単に過去データを扱う必要があるからやろ >>224
出力する時だけ元号処理噛ませりゃいいだけだと思うんだがな でも冷静に考えてこんなんでも受入テスト通ってるんだろ
銀行も相当駄目なんじゃない
>>237
元号が変わることなんて考慮しなくていいから、その分費用削れ
…ってところだろ >>236
最近のシステムは必要部分だけ変換処理噛ませて対応してるから影響は軽微だと思う
銀行みたいな内部の業務まで和暦使ってる組織はシステムにまで和暦が組み込まれてるから厄介かと 彡⌒ミ
(ヽ´ん`)1989年5月7日か・・・あの頃に帰りたいな
北陸とシステム共同利用の浜銀と道銀も巻き添えになってて草
多分西暦~和暦変換処理がバグってて令和1年→平成1年→1987年みたくなってるんだろ
>>246
2019年5月→令和元年5月→(元年5月→"平成"元年5月)→1989年5月
括弧内がやらかし https://pbs.twimg.com/media/CAq988oUUAINVU0.jpg
Twitterでも1970年のツイートが話題になってたよね
UNIX時間を知らない人は怪奇現象だと騒いでたが >>242
西暦の下2桁から元号を求める自作ルーチンで
引き算だけじゃなく割り算も使っていたんだろうさ
それでゼロで除算しちゃって
アレな事になったんだろうさw >>246
システムが和暦で動いている
連休明けの5/7は和暦1年5月7日だ←システム対応済み
和暦→西暦変換処理のプログラムは5/1に和暦+1988から和暦+2018に切り替えればいいよねー←アホ
振込するの?翌営業日は和暦1年5月7だよ
画面には西暦で表示するから1988を足すね! >>223
開き直って第一勧銀のハートマーク出して欲しい 世界の車窓からのBGMと共に富士通のロゴ表示して押し付けちゃえ
(; ・`д・´)「かんたんだよ。元号を使わなければいいんだよ」
銀行のシステムってのは
月初第一営業日っていう概念があるんやで
それを知らない非金融系や
勘定系を知らんIT土方だと
判らんだろうなw
システム上では既に令和元年なんやでw
ギリギリまで元号発表引き伸ばした右翼のせいで
西暦以外使いたくないという日本人が増加
内部で和暦処理してるっぽいな
3なら昭和4なら平成5が来たけど平成で処理されたんだな
年度処理の副産物かな
新元号に切り替わる直前のローソンATMがまさかのタイムマシンで…というストーリーでアニメ作れるな
横浜銀行も同じような不具合起きてるけど、日付が4/26ってすごいな
連休直前に発覚なら関連システム屋は全部の予定取り消し確定じゃん
----
https://www.boy.co.jp/news/emergency2/1245651_8285.html
お知らせ
お詫び
2019.4.26
このたび、コンビニエンスストア内のATMにおきまして、お振込みをご利用されたATM画面とご利用明細に、一部表記の誤りがあったことを深くお詫び申し上げるとともに、ここに訂正させていただきます。
お振込予約日
誤→1989-05-07
正→2019-05-07 >>249
始発点の西暦産出がすでに、昭和n+1925 >>260
和暦で動くシステムなんてねぇわw
日立の汎用機ですら西暦で動くわw
DBには全て西暦で記録されていて
ATMの画面表示や帳票出力時に
必要に応じて元号変換して
和暦として印字されたり表示されたりするだけや >>52
5月7日までに原因突き止めて直すつもりだから実害ないと発表してるとしたら…
もし直らなかったら振込先巻き込んでやらかしそう NTTデータ社員の担当者の休日がパー
ざまぁwww
セブンATM方式で各行の独自プログラムが動いてるならローソンのせいじゃないな
当時の俺に500万振り込んでくるわ
これで俺の人生が変わるぜ
関係者だけがイロイロずる出来るように穴でも開けてたんだろどうせ
>>275
下請けを怒鳴りつけるだけなんだよなぁ…。 >>250
2038年が楽しみだな
もっともシステム屋はまさしく火中だろうが しかしおまえらはIT土方が多い癖に
どいつもこいつも下流のコーダーばかりで
上流を知っている奴が皆無なのなw
>>275
NTTデータなんだ
NTTデータはたしか1か月あればシステム改修楽勝とか言ってたな
馬鹿じゃねぇのと思ってたけど案の定やらかしてワロタ 個人の趣味で平成とか使うのいいけど
公のすべては西暦でやれや
なるほど、コレなんか
MEJAR
正式名称は、NTTデータ 3行共同利用システム。「MEJAR」は、Most Efficient Joint Advanced Regional banking-system(最も効率的な先進的地方銀行共同システム)の
略から取った名称。NTTデータ地銀共同センターと横浜銀行・北陸銀行・北海道銀行の共同開発。3行とも従前は富士通メインフレームだったこともあり、同社メインフレーム
で稼働している[2]。
2016年1月には、富士通メインフレームの勘定系システムを独自に採用していた七十七銀行が「MEJAR」に移行[3]。
また、2019年1月、横浜銀行と同じ持株会社の傘下に入った東日本銀行も「MEJAR」に移行した[4]
(同行も元は、富士通メインフレーム行である)。第二地銀の利用は東日本銀行が初。
横浜銀行 - 2010年1月4日稼働開始[5]。
北陸銀行 - 2011年5月6日稼働開始[6]。
北海道銀行 - 2011年5月6日稼働開始[6]
七十七銀行 - 2016年1月4日稼働開始[7]。
東日本銀行 - 2019年1月4日稼働開始。
俺の人生の中で唯一のモテ期だった頃だわ
戻りてえなあ
子供「なんで旅行中止なの?」
ママ「急に仕事でダメになったの」
IT土方パパ「すまぬ、すまぬ!😭」
>>292
ここまでシステム化されてなかった
基本手作業 だったから これ半分どころかすべてギリギリまで元号発表せず世の中混乱させた安倍と自民党のせいだからね
請求は彼らにお願い あ 税金じゃなくて個人資産でお願いしますね
あと2日で終わる平成を噛みしめる為のLAWSONからの粋な計らいだろ_φ(・_・
馬鹿だな
西暦ベースにして和暦を変換表示すればいいものを
西暦でバグるのはおそ松すぎますぜ
金融機関のくせに元号なんて時代錯誤なもん使ってんじゃねえよ
西暦でやれ
>>294
やはりジャップ企業はダメだな😩
ふじた_🐱♨💻雑用係 (@nfujita55a)さんが1:59 午前 on 水, 12月 06, 2017にツイートしました。
新元号対応の話、マイクロソフトの回答が誠実。
マイクロソフト:改元は極めて複雑な、非常に多くの検討事項や作業が必要
NTTデータ:元号改正による修正は限定的
日立製作所:平成から新元号への対応は比較的容易
(https://twitter.com/nfujita55a/status/938090412526288896?s=09)
https://twitter.com/5chan_nel (5ch newer account) 2000年問題みたいなことが今起きてるのかよ
ガイジか
和暦なんてシステム的には表面の見せかけじゃん
そんなことでバグ出すなよ
>>305
windowsってレジストリに値持ってるんじゃ無かったっけ
システムによって影響範囲が違うのは仕方ない
今回のは見切れてなかったから非難されて然るべきだけど >>305
マイクロソフトは実際に1月にやらかしてるからなぁ・・・
あとIT業界のサグラダファミリアで苦しんだ富士通の回答も入れてやれよ
https://developers.srad.jp/story/17/12/11/0823204/ クソみたいな元号をいつまでも使っているからこうなる、とっとと終わらせろよこんなモノ
おまえらが大昔に立ち上げて
放置しているホームページでは
古いperlを使って無理矢理西暦表示させていた部分で
19119年なんて表示されていたりするんだろ?
>>308
至極単純な西暦下二桁システム
昭和時代は、昭和n年+25でおk
平成に変わったら、昭和n年+平成m年+25でおk このあと隠しボスの消費税2桁がくるんだぜw
おわっとるわ
IT土方はまともなやつは殺されるから
さっさとやめた方がいいぞマジで
俺はやめたよw
>>310
大元が和暦でデータ渡してくるから仕方ない 元号採用してる国って、裸で槍持ってる部族くらいしかもう残ってなくね
>>315
お前のレス痛々しいな
世の中の全員がプログラマーだと思ってるのか? >>325
元号をね
基準の年データとしてもってるウンコしすてむが大量にあるんだよw
とくに金融系は基幹が腐ってるから
どうしょうもないww 俺に頭下げれば1ヶ月で半永久的に使えるシステムアセンブラで組んでやるのに
最近暇だったのになあ
銀行ってこんなにも和暦が浸透してるのか
さすがに最近システム刷新した銀行は変わってるのかな
千葉銀行系列とか大丈夫かね
中国銀行があるのだが
>>21
この手のってドカタより上の管理してるやつの頭が悪いんじゃねぇのw
コーダーに罪はねぇよw >>334
もともさ
オフコンとかホスト時代の基幹が生きてるとこがほとんどだからなw
そらそのころのアフォジャップコボラーがかいた
うんこなんだから
ジャップ暦つかわれてないところのほうがめずらしいわww 和暦で動いてるやばめなシステムを計算で対応するなよ
すなおにカレンダーのDBつくれよ
>>330
ロジックがよくわからん
内部データが和暦管理?
内部データが西暦2桁で元号とのセット管理? >>334
他との連携を考慮すると
既にその業界のシステムではデファクトとなってる方式に合わせると思う
そのデファクトが和暦なんだろう >>327
俺ちゃんはプログラマーなんかじゃねぇわw
歌って踊れる社内SE様だったわ
1年ちょいで辞めたけどさw
今は我が家の不動産物件管理会社兼資産管理会社で導入した
SAP Business Oneを
代表取締役社長兼一人情シス部員として
一人でチマチマメンテしているわw
ちなみに弊社の基幹システムは
俺ちゃんがたった一人で
令和対応を済ませたわw >>340
基本和暦なんだよw
必用にせまられたときに和暦を西暦に変換するクソしようなんよ
しかもテーブルとかじゃなくて
手書きでウンコif分で分岐してるよww
まじでジャップのコボラーなめんなよwww せっかくの改修チャンスだから元号対応ではなく元号使わない方向に改修すべきだったな
>>272
それがあるんだよね
日立のとある会社のシステムでもホストの処理は和暦が基本になってて、和暦2桁に対応する和暦は1つしかない設計になってたりする
01だったら常に平成元年とみなす、とかね >>343
ねーよ
システム屋が内部的に和暦持つなんて有り得ん >>340
勘定周りで和暦使ってたから基本和暦でやってんじゃね
日本でIT IT言われだしたのここ20年ぐらいだし当時はオブジェクト指向なんて考えも流行ってないから継ぎ足して使ってんだろw >>345
日立は本当にアレだからな
富士通もかなりアレだけどさw >>347
そのシステム屋なんて概念が生まれたの最近だろw
たいていは自社の少しわかるやつかベンチャーの若いガキがやってた
言われるままに和暦軸に作るのは十分ありえる >>354
1900年代には既に2000年問題が見えてて和暦なんて論外 この状態で金借りたら、利息がマイナスで儲かるみたいなことになってない?
なってたら100万ぐらいすぐ借りるんだが
ちなみに令和対応フォントは
IPAの岡ちゃんが
無償公開してくれているぞw
>>347
コレが平成生まれの酸素欠乏症ってヤツか
お前、自民党好きそう いやマジで信じられん
普通はグレゴリオ暦で日時を持って、和暦表示だけ一方通行でアウトプットするだけにするのに
大昔のシステムってやべーな
>>363
もうUnicodeで定義されてフォントもいくつか作られてるみたいよ >>366
俺たちの岡ちゃんは
根っからの割れ厨だからなw >>57
なんで和暦を西暦に変換したと思ったの?
西暦を和暦にする際のロジックがおかしいと思うのが普通じゃね? >>356
2000年問題は1998年になって初めて問題が露呈したんやで >>370
銀行屋は、改ざん隠ぺい黒塗りでお馴染みの霞ヶ関様より元データ貰ってる&納めてるからや
霞ヶ関様は元号絶対信者やで 安倍が天さんの思い通りにやってればこんなにならなかったのになw
えっ、内部処理をわざわざ元号でやってんの…
何でそんなガイジムーブしてんだよ
西暦使えないぐらいメモリ逼迫してんのか?
>>375
そんなもん当然に西暦変換すりゃエエやん 貧乏だった過去の自分に振り込んであげたい
と思ったけどいまも金なかったわ
>>380
自民党と天皇倒すとこから始めならならん >>383
NTTデータがATMを担当してんの?
POSはNECで新ローソン銀行はIBMとか見たが? 重大トラブルやりそうなベンダー
本命 富士通
対抗 NEC
穴 日立
大穴 IBM
そういえば30年前に謎の入金があったんだけど
これだったのか
障害報告書
件名:
和暦→西暦変換ロジックにおける
新元号対応漏れ
内容:
和暦「01」からの西暦変換で
元号コードを平成のままにしてしまい
→「1989」という変換を実施
なのか?
元号コードが平成の場合の和暦「31」以上からの西暦変換ロジック改修で
マイナス30にする事は実施したが
元号コードを令和にするロジックが抜けており
「1989」に変換されてしまった
なのか?
ふーん
MEJAR単体のバクなんだ
ダサ過ぎっしょw
ローソン銀行は新規参入だから、全く想定しなかったんだろうなー。
去年稼働スタートだったよね?
>>391
その前提は元データを未だに和暦で持ってるてことだよね?
表示じゃなくてデータ自体を西暦変換して持ち直すっしょ? >>391
これは対応漏れじゃなく
仕様の範疇ってか
想定済の不具合だろうさ
改元を跨ぐ10連休中という
翌営業日=月初第一営業日
な間のうちの
旧元号期間だけの例外処理を
わざわざ追加しない事による
想定される弊害 >>1
これ銀行側が画面にこう表示して、こっちが「確認」ボタンを押したら
明らかに契約が成立するよな
ローソンの必殺技・タイムワープ振り込みを見せてほしい >>266
まああくまで移行期の表示上の問題だからなぁ
どうでもいいと思うけど
まあ元々は元号なんて使ってるジャップが非生産的なキチガイなだけだけどw 30年前に1億くらい預金しといたことにすればええんか
改元もしないうちからこれじゃ5月7日の朝9時が時限爆弾なんだが
インフラ系でぜったいやらかすぞこれ
>>404
ジャンルを問わず
ありとあらゆる企業が
(ノ∀`)アチャーな事をやらかすと思うわw 素朴な疑問なんだけど
元号変わる前提でシステムって構築されてないの?
今回は事前に譲位するって告知されたけど
普段は崩御して元号変わるから事前告知なしだし
>>397
西暦で内部ロジック組んでて表示だけ和暦変換するようにしてれば、そんな例外処理いらない >>408
必要になった時でいいからその分の費用削れって顧客要望 >>407
ATMの他には食品の印字ミスなんてのもあり得るな
生産管理系も馬鹿みたいに古いシステムで動いてるとこ多いから >>60
1万円だけ取って9万円交番に届けたら半分貰えるんか >>412
なるほどって納得できない
要望出した顧客側も凄いこと考えるなw 券売機や検索の端末ってXP使ってることあるから令和アップデート去れないで
5/1に障害起きたりしないのかな
>>408
一言で改元対応と言っても
そんなに単純じゃないからな
こういう感じの部分は
逆にシステマチックに
事前対応するが簡単な部類
帳票処理だと新しい元号に使われる
漢字の幅に合わせて
印字位置を微調整したりするので
新しい元号が決まらないと
対応する事が出来ない >>417
システム屋も、改修費用もらえるなら…ってことで無批判にその要望を受け入れちゃう >>383
今頃、右往左往してるわ。
しかも北陸。。。 >>419
Linuxじゃねぇの?w
知らんけどw 元号残してもいいけど使うのやめようよ
日本経済にとって凄いマイナスだろ
これ入金したら30年分の利息付くとかいう付加バグ発生しないの?
>>424
ブルースクリーンになってるのよく晒されてるからググってみ >>5
さくら銀行は1992年~
改名前の太陽神戸三井銀行も1990年~
1989年当時は三井銀行と太陽神戸銀行 >>422
違うよ
MEJARてのを構築するときにやらなきゃ駄目なんだよ
他のベンダーは西暦化含めて提案=高価
NTTデータは取り敢えず統合してから考えましよ=安価
それで後者が採用されたと考えるのが自然 >>424
Windows2000やXP Embeddedが
バリバリ現役な世界やでw
海外だとLAN対応なwfw3.11なんかも
バリバリ現役だったりする
日本だと日本語版wfw3.11が出なかったお陰で
スタンドアロン環境以外では
DOSや16bitWindowsは壊滅しているけどw ついこの間銀行業やり始めてもう不具合かよ
担当者はまあクビやろな
>>439
外注の不手際にする書類書いて終わりだが 2000年問題で結構騒いだんだから、令和問題ももっと騒がれてもよかったよな
こういうニュースを見ると
>>437
そういう1行レス止めろよ
提案て書いたよね?無批判とは真逆 気軽に使ってもらうコンビニATMで不具合とか一番やっちゃいかん奴だな
信用無くなって誰も使わなくなる、コンビニも敬遠される
これ本当に怒られるべきはpgじゃなくて評価部門だけどな
半年前に公表しろとさんざ言われて結局1ヶ月前だもの
そりゃこうなるわ
損害は全部自民と日本会議の口座から払って貰おう
>>445
なぜその提案に至ったかってことも考えてみてね >>451
コーディング末節な話しじゃなくてインテグレータが無能
外注の外注のバイト君が書いてるだから低レベは当たり前
なんだかんだで>>388の企業はそれに長けてる >>452
ブツをスルーで受け入れちゃった奴が
始末書を書かされる事案やなw >>456
これはDCSがやらかしたと言って
過言ではないと思う
DCSも専門卒の低学歴ばかりだからなw >>458
責任がないからな
そりゃバイト君ならそーするわ
だからこそマネージメントがしっかりせんと
その代わり上記の大手ベンダーさんは技術力がないんたけどw 未だに昭和で動いてるうちのシステムは安泰だな
なおそろそろ昭和100年になり桁数オーバーした際の影響は不明
>>444
技術大国 とか 常に正解を導き出す最高先進国 とか 間違わない選択を常に選んできた選民国家 とか 忖度 とか
色々とおごりがあって
騒いだら負け、疑問に思ったら負け
で、選ばれし指導者に導かれ、いつでもどんな時でも余裕のあるスタンスを他者に見せつける
それが神が降臨してから2000年続く世界に選ばれし国、にっぽんー!
なわけで
祝賀ムード一色にする事だけしか考えないから
問題対策なんてはなから眼中にない >>454
いや同情要らんぞこんな基本的なもん
絶対システムテストやってねーわ
客先常駐はPMもアーキもアホ揃いじゃ いつも通りに天皇の崩御からの改元でも同じだったろうから元号発表が遅いとか関係ない
>>421
フォントによる印字位置のズレとか微調整とかが必要ってことか
OSもシステムフォント変わるとアプリ側で微調整して対応してくから
大変なのか >>422
>>434
まあ元号くらいなんとかなるかってことなのか
事前に発表されてこれだから対応する側は大変だ >>345
これはメーカーや当時の担当を責めるべきではない
そもそもシステムなんてのは基幹であろうと本来は長くても10年くらいの耐用年数を設定してるし
日進月歩で進化してる世界だからそれくらいのサイクルでより効率的なシステム、ソフトウェアに移行している想定だから
こんなに日本企業のITや業務効率化の理解が進まず経済が停滞して20年も30年も使われる続けるなんて思ってもいなかったんだから >>468 結果は一緒だろうが今回は一年もの時間的余裕が有った >>234
全銀フォーマットがそもそも和暦でYYMMDDが基本で、
モノによってはMMDDだけのものもある。
と書けば深刻さは伝わるかな。 >>468
ネトウヨがいう正常バイアスは、ガチ危険案件 >>474
なのでいつもより1カ月早く発表されただけマシだな >>470
やっぱり過少報道だな
華やかな式典に水を差すなってことか >>469
判りやすく例えると
おまえも年賀状を出す時は
Windows版の年賀状印刷ソフト等でも
郵便番号の印字位置を
ハガキ側の枠に合わせて
微調整したりするだろ?
あんな感じで印字位置を微調整したり
場合によってはオーバーレイ側っていうか
枠組側をも微調整したりするんやで 令和にならず平成のまま繰り上がっちまうならわかるけどなんで西暦で巻き戻ってんだ
>>482
年賀状は上下左右で0.1mm単位で調整する
年賀状よりフォントが小さいからもっと細かい調整をあっちゃこっちゃでやるってことか
場合によっては帳票側の調整も必要だから確かにめんどいな
システム以外にも印字面とかがあるのか >>127
いやー違うと思うぞ
画面の表記だけ間違える方が難しいだろ
1989年5月7日としたら永遠の処理されないだろうな
それに5月1日から全て1989年扱いになってると他の処理もやばい >>485
基本知識として「全銀フォーマット」は和暦YYMMDDってのがある。
これは「日本に存在するあらゆる銀行間、あらゆる口座間の、あらゆる資金移動・決済で使われるデータフォーマット」と考えてくれていい。
で、4/29において振り込み作業を行ったときに、実際には5/7に振り込みが実行されるとなるんだが、
その振り込み電文はこんな日付になる
・操作日が310428
・処理日が010507
その情報をもとに画面を表示するわけだが、その際「この年号の和暦がいつを指しているのか」を
操作日ベース ("平成" 31 年) で決定していて、
処理日の 01 が "平成" 1 年と出てしまった、とかかなぁ……。 このパターンだったら、電文の日付自体は適切だから 2019-05-07 処理になる筈。 >>466
でかいシステムだと本番でやるなんて絶対無理だから当然だと思うよ
一ヶ月なんて短すぎる >>492
そもそも日本ってのは、世界でも有数なぐらいにオンラインとか電子化が進んでいた国。
それこそアメリカとタメはれるぐらいには先進的にインフラ構築してたわけだ。
で、その時代は日本は「和暦」前提で社会のすべてが動いていたと言っても過言じゃない。
国も、地方公共団体も、民間企業のあらゆる書類は和暦ベースで動いたわけだ。
西暦前提で日本社会が動くのは、本当にここ20~25年の話で、
それまではずっと和暦を前提に社会が組まれていた。
オンラインシステムなんかは、そんな時代に作られたわけだから、
そりゃ和暦を前提に作ることが合理的だったのは間違いない。
最初からなんで西暦で組まなかった、ってのは「お前に予知能力がないのが悪い」っていうのと同じ。 俺が昔作ったシステム、西暦下2桁+12で平成表示のままで動いてるけど大丈夫かな…
過去に金を振り込むことによって
何とかして大金持ちになる方法はあるか?
>>491
役所を除いた民間のシステム元号使ってるのなんて
それこそ金融くらいだぞ 運用コスト○割減にしろ!と客がやってるから、古い処理とかみんな中分からん状態だぞ
加えて単価の安い人間つかすからいろいろボロボロ
>>495
和暦前提ならなおさら改元を考慮してないとおかしいやろ >>505
そりゃ考慮もしてるしテストもしてるやろ。
そのうえでテストケースもれとか出たってことでしょう。
後出しじゃんけんで「一番最初にやっておくべきテストケース」とか言っちゃう?
それこそ「予知能力がないのが悪い」と変わらんぞ。 もっと協力なやつ来ないかな
飛行機のシステム落としたり原発の冷却止めたりするようなの
>>417
さすがに20年後はもっと新しいシステムになってるはずだよな?
このシステムとしてはそれより先は考える必要なくね?
というのがシステム開発あるある >>507
こんなのがテストケース漏れになるようなシステムwww >>513
よくあることをバカにしてるんですがなにか? それはそうとバブル世代はバブルに帰れよWWWWWWWWWW
平成でも
令和でも
発狂してるのは無能バブル期中年WWWWWWWWWWW
バブル世代はバブルへGO!!!!!!!!!!!!!!!
>>19
ローソンはイーネットじゃねーの?
あれMUFG? >>508
自分には関係ないからー
でボケてる一般国民にはそんな惨状より
ATMシステムクラッシュで金が出せない送れないになる方が
ガチで効くから >>511
20年後くらいの運用側は「20年近くも実績あるPGMだから修正に必要ないだろ(根拠無し)」
となるのがあるあるだわな >>488
実際の計算はユリウス日で、お客様表 示用の数字へ変換する時に、処理の最初で年月日なり平成なりに加工するのだと思う
それならば目で見える数字だけが全滅でもおかしくない >>517
中身はMUFJベース
が、これエラー出てるとこの関係見ると、NTTデータ 共同利用システム
(北陸銀行、北海道銀行、横浜銀行)側のエラーかもしれんね 地銀の共同システムってどうなってんの?
物理的に共同のセンターがあるの?
それともおんなじソフトとマシン揃えてやってきましょうって感じなの?
だいたい一番デカい銀行のシステムを手直しして、他の銀行が相乗りするイメージ
遠い銀行の元メインマシン置いてたとこに災対がおかれるとか
まさか最終的なアウトプットだけじゃなく、内部も元号で処理してんの?
元号表示を間違えるならまだわかるが西暦表示を間違うってどんなバグなんだ
日付を元号で管理してるのか
全銀フォーマットが全ての原因
何で元号区分ないねん
たぶん銀行以外も5/6明けか5/7明けでなんか起きるんじゃねーの
ただでさえ連休でバッチ溜まってるのに加えて、なんかバグ出て
バタバタするんだろうな
これ、確認ボタン押したらこのトランザクションどうなんのw
永久に処理されずに残り続けんのかな
ATMでデュープバグ探しとかネトゲより楽しそうだな
>>532
「こんなに長く使われるとは思わなかった」
「時代に合わせて更改していかなかった後継のやつらが悪い」
だいたいこれ >>542
>「こんなに長く使われるとは思わなかった」
更新の提案しても一蹴じゃないですかやだー 全銀フォーマット見たらMMDDしかフォーマット上ないのな
受け取ったデータ上はおかしくなってないだろうから、YYYYつけるとこ
リランして残りやればいいだけか。わりとリカバリは楽そう
これ貯金消えたりしないの?
考えてみればある日、貯金が0になってもおかしないよな
通帳に記載されてるのはただの数字な訳で
ワイが現物を持ってる訳やない
ある日、通帳の数字が0になってもどないしようもないよな
銀行からお前が下ろしたんやろと言われたらしまいや
そう考えたら怖くなってきたわ
山本太郎ちゃんに寄付金振り込もうと思ってたけど後にするわ
大切な寄付金がバグって0円になったら困るからな
>>530
そうだぞ
基幹システムがCOBOLでうごいてるウンコ企業の常識やゾ これはまだ可愛い方でさ
消費税が2桁になったら核爆発おこすシステム
指の数ぐらいは最低しってるんだが
あいつらどうするつもりなんだ?
>>556
ジャップがバカじゃないとでもおもってたのか
このバカが >>19
いや、北陸銀行が原因って北陸銀行が言ってるっぽいよ
ローソンのATMで他の銀行もそうなるのか? もうどこも経営よろしくないから
木に竹継ぎ足すようにやってくのかな
刷新するのってかなりハードル高そうなんでしょ
元号で表示するときだけ変換すればいいから起こらないような気がするんだけど
内部データが元号で表示するときに西暦にするという面倒な仕掛けなのか?
>>562
つか元号管理
それも月/日だけの元号管理 ツイッタみてたら復旧は明後日の改元日到来待ちってあるけどそれでええんやろか
それまでは発生したデータを人力テーブルアップデート対応とかするんかな
たぶんテストでは5/1以降まともに動くの確認出来てんだろ
明日だけのために今から画面表記直すより、後始末の対応やらせた方が安全
マジかよ
俺も1989年に戻って何もかも最初からやりなおしてえ。。。
結局、テストだチェックだなんだって「やってる感」で言ってるだけで
ちょっと動かせば分かるような問題は放置なのよなw
配列や定数ミスにしろテストで気付かないもんなのか?
振込予定日がなぜか「1989年」に、コンビニATMで不具合 | 日経 xTECH(クロステック)
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/04881/
少し詳しめ >>571
元号対応なんて「仕方なく」やるもんだか、客もモチベーション低い
金融庁が「問題出すなよ」とか通達してるが、無理なもんはむりだわな >>584
まー勝手に変わるもので合わせないといけないし
ほんの少し前までは省庁が元号にしとけとずっと言ってたわけで
銀行とかからすりゃいい迷惑でしか無い話だわな 日付間違えなんて手作りの時刻ライブラリを使った恥ずかしいPGなんだろう
内部データが元号って金融系じゃ普通なのか
そういうとこ行ってなくてよかったわ…
モアタイムに参加してない20行程度のために残してる、旧対外系の処理で平成の罠が入ってたか
こんな処理部分だと工数かけてないだろうなー
影響調査
データ修正依頼
横展開
再発防止策
考えただけでもチビる
>>524
銀行のプログラムなんて継ぎ足し継ぎ足しで作ってるからユリウス暦なんてありえないわ >>598
IBMホストの日付はユリウス暦
第三次オンラインの頃はIBMか、それをパクった国内メーカーのホストマシンで仕組み作ってるから
ユリウス暦でやってやがる可能性は一応ある。YYYYMMDDが大概だろうけど >>601
あのね 元号YYMMDDでMMDDしかないのも沢山ある
ての絶対に認めないよね、お前は
何者のつもりなの? 工作員? 子供部屋再設計おじさん? ここだけの話だが
JRのきっぷって、「昭和」でデータ管理しているらしいぞ
つまり、昭和99年→昭和100年になったら、ゼロに戻ってしまうんだそうな
1926年=昭和元年
2019年=昭和94年(しかし、マイナス63して平成31年ということにしているらしい)
ということは、2026年になったら・・・
今はデータ通信速度も保存容量もケタ違いに増えてんだからとっとと電文拡張しろよ
・・・と思ったら、次世代フォーマットは一気にXMLになっちゃうのなw
https://www.zenginkyo.or.jp/abstract/efforts/smooth/xml/faq/
https://www.zenginkyo.or.jp/fileadmin/res/abstract/efforts/smooth/xml/XML_EDI.pdf
まぁそれなら旧式電文との混乱はなく、和暦だ西暦だの心配も一発で無くなるが
今度はタグさえ切れば怪しいメッセージも忍ばせ放題じゃないのか?という 30年前になぜかローソンから振り込みあったのはコレか(´・ω・`)
>>605
その頃になればさすがに完全な新システムに移行してて今のシステムなんて微塵も残ってないからダイジョーブ
なんて40年前から言ってるんだよねえ… >>5
0002だっけ?
みずほが0001
三菱が0005 >>605
次期マルスでちゃんと改変されるのかね
無理そう つまり、ジャップ式UNIXタイムを作り出してたってオチか
こんな昔に振り込んだら、金利で何倍かになるやろな。
>>71
(´・ω・`)みずほ → これ以降のお取引の日付は西暦で印字いたします。
(´・ω・`)ろうきん以外 → 和暦
(´・ω・`)信金はどうなんだろうね >>490
実際に実行したらブラックホールに
お金が吸い込まれるって事例が発生しそうだなw >>524
そうなんだけど
実際にこうやって見逃してたってことは
内部の処理もそのままになってる箇所が残ってる可能性はあるんだが 下手すると入金先のシステムまで巻き添え食らいそうな気がする
>>627
さすがに全銀ネットでは不正データは弾かれると思いたい >>45
ギリギリすぎて何万とある検証作業が出来ない。
よく予めある変数の中身変えるだけでいいとかアホな意見あるが、想像を絶するテストをクリアさせるには時間が足らなさすぎる。
一ヶ月前に発表できる感覚を持った人間が権力を持つこの国の未来は暗すぎる。 今は知らないけど昔の国道10号の鹿児島の海沿いは怖かった。
右車線をものすごいスピードで走り抜ける車ばかりで
通過速度を表示する電光掲示板みたいなものを見てたら
100とか140とか出てた。
こんな大手でこんなしょぼいバグ出るようじゃ1日が思いやられる
「令和」という名称であること自体は改修と直接関係がないから
事前に8割くらいの対応は可能なんだけど
基本的には直近までGO出ないよねこういうの
>>630
本来は天皇がなくなった翌日から新元号だから
もっと余裕がないんじゃないのかな >>634
むしろその方が、どうしても必要な箇所以外は割り切ってゆっくりできそう >>635
日本企業だと何がなんでもとにかく速く対応させろこの野郎!とかじゃないか >>634
だから天皇自体はそういう自体も想定して半年以上前の公表を考えていたのに、アホな保守派がそれをダメにした。権威だの何だの昭和でアタマが死んでる連中。 >>526
>>534
>>582の記事みると違うようだよ。関係はしてるけど。 振込データが6桁YYMMDDで元号から西暦計算するのにYY+1988(平成元年の前年)って計算してんのか?
>>526が書いてる以外の銀行からの振込データだが、そんなパターンあったわ >>570
俺も高校卒業したら東京に行ってやり直したいよ >>506
https://www.zakzak.co.jp/soc/amp/190403/soc1904030018-a.html
明治天皇の玄孫(やしゃご)で、作家の竹田恒泰氏は「日本は701年の大宝律令で、元号が制度化された。
以来、公文書はすべて基本的に元号で書くのが決まりだ。聖徳太子は、中国の皇帝とやり取りするにも
『独立国家の証し』として日本の元号を使い、書をあてた。そんな先人や歴史を外務省は何だと思っているのか。
外務省こそ元号を重んじないといけない。聖徳太子も泣いていると思う」と語った。
日本で元号が使われたのは、「大化の改新」以降じゃなかった?
聖徳太子の時代に元号なんてありましたっけ この無能ITドカタが!そんなワープロみたいなのさっさと治せよ
>>496
2000年問題より深刻になりそう
休みだしテストしてねえしで ビジネスに元号を関わらせない
それだけで済む話しなのに
表示は西暦なのに内部は元号で管理してんの?
アホじゃない?
UNIXエポックどう処理するつもりなのか今から楽しみだわ
80年代の全銀ネットがそのまま来ちゃったことが原因のようだけど、今から刷新することってできるの?
>>547
引き出しや振込のデータが残ってないから
バグかどうかは一目瞭然だと思うよ
で、5/1や5/7になってヤバイことが起こるシステムあんのかね
表示がバグるだけなら問題ないが たった一か月しか期間なかったし、この程度で済むとは思っていない
これから似たようなことボコボコ起こるぞ
ったく面倒くさいな
いつまでも元号にこだわらず西暦でいいじゃん
世界よ、これが日本のソフトウエア技術だ
どうだ、怖いか?
>>284
データ本体て驚くほどITに無知な人がプロマネとかコンサルやってるよね
あんな感じなのに中央官庁、自治体、金融機関のシステムの相当数を請け負ってる
あ、ジャッだねと思った >>605
JRのシステムってどこがやってるんだろう
東日本、東海、西日本とかで違うとこがやってそうだが >>351
日立は本体でもシステム系の人にはキチガイがいたね
文字通りの人格障害みたいなの
お前だよS 現代からローソンを通して平成元年に送金されてたならバブル景気と失われた30年の説明が付くな
>>654
そら指揮ってる霞ヶ関のお役人さまたちには無理だわな
やつらはビジネスじゃなくて役所仕事なんだから >>662
天皇を中心とした世界を征する神国
の威信に関わる
神がご降臨して以来2000年、我が国は下々の野蛮国に屈したことは一度もない
が政府官僚の回答 こういう時の為にメインバンクをみずほにしてるところがあるからな俺は
今からどんなハプニングに巻き込まれるかワクワクしてきたゾ
>>605
うちの会社のシステムも内部は平成で管理することになったわ
「その方が改修費が安いから」だってさ
目先の改修費ケチっても
今後のメンテが高くつく(分かりにくいから)だろうに
ほんと上司がアホだと苦労するわ 1989年表記の利用明細書を記念にゲットしようとすると振込手数料かかるのか
振込んで応援になるのか
ATMの開発か抜けて正解だったわ
将来なんの役にもならん
>>680
やっぱこういう案件に携わるのは三下エンジニアだよな
技術的に誇りを持ってるエンジニアはもっと別の案件に行くし
課される責任と報酬を考えたらATMには人来ないだろうね 2050年も楽しみだ
西暦2桁から3桁化した時の名残で50比較してるコードがありそう
…つーかアレどうすんのかなぁ
場当たり的な対処で50を75位に書き換えるんだろうか?
2038年も大きいはず
1981年からの秒数が32bitの限界を超える、64bitなら回避できるが当時そんなの存在しないし33bitめを考慮するわけがない
2000年問題は組み方の問題だけどコンピュータの仕組み上回避できない問題の対応も楽しみ
振込予定日がなぜか「1989年」に、コンビニATMで不具合 | 日経 xTECH(クロステック) - https://tech.nikkeibp.co.jp/atcl/nxt/news/18/04881/
ただしトラブルはMEJAR以外の周辺システムで発生したもよう。周辺システムはNTTデータ以外のIT企業が開発したとみられ、3行とNTTデータなどは原因究明と修正を進めている。 >>641
(´・ω・`)なんかマヌケに見えるからタテ棒はしっかり書くようにしてる >>683
実は2038年問題は、2004年に一部でボヤを出してる。
それほど大きい被害ではなかったそうだが。
どんな問題かってーと、ふたつのタイムスタンプAとBの中間、A'を求める際に
A'=(A+B)/2
なんてやってたコードが以下略
まあそんな処理をする必要のあるシステムはそれほど大きくないしってことで
大火事にはならなかったようだが。 >>684
問題あったのMEJARじゃねーからッ!って言ってるけども、ブランド価値下げないために範囲外って言っとるんだろうな
別に余所も使ってる汎用パッケージってわけじゃないんだろ 西暦表示でなぜバグる
いちいち元号に変換してんのか
>>689
基本知識として「全銀フォーマット」という書式は和暦YYMMDD前提ってのがある。
これは「日本に存在するあらゆる銀行間、あらゆる口座間の、
あらゆる資金移動・決済で使われるデータフォーマット」と考えてくれていい。
そもそもYYすらないフォーマットもある。
で、4/29において振り込み作業を行ったときに、実際には5/7に振り込みが実行されるとなるんだが、
その振り込み電文はこんな日付になる
・操作日が310428
・処理日が010507
その情報をもとに画面を表示するわけだが、その際「この年号の和暦がいつを指しているのか」を
操作日ベース ("平成" 31 年) で決定していて、
処理日の 01 が "平成" 1 年と出てしまった、というのが恐らく真相。
このパターンだったら、電文の日付自体は適切だから 2019-05-07 処理になる筈。
すげぇ雑に言うと、銀行間・口座間の資金移動は「和暦」を前提に設計されていて
今でもそれが使われている。
途中で必要に応じて西暦変換はするだろうし、各種口座やらなにやら
データベースストレージに西暦ベースで格納されているかもしれないが、
「資金の移動」という事になると、和暦から逃れられない。 旧式フォーマットの場合はそのまま受け容れるマルチフォーマットに移行すればよかったのにね
発想はあったんだろうけど
なるほど、当時の設計者が「西暦は敵性言語!」みたいなやつだったんだろうか
それか和歴の方が雅があるとか考えてる運用度外視のウヨか
>>693
というか
天皇が治める神の国
神が降臨されて2000年以来1度も侵略されてない神聖国
がこの国のお役所の決め事なんで
お役所が統率する金融は和暦しか選択肢がない >>683
デジタルテレビを見るためのB-CASカードが、まさにそれ
2038年04月22日で使用不可能になってしまう
あと19年だ >>693
当時は社会の全てか和暦で運営されてた時代。
官公庁から様々な民間企業や個人商店に至るまで、
政治も経済もほぼすべて和暦。
西暦が社会に使われるのなんて、20年ぐらいだぞ、長くて25年。
西暦なんて、コンピューターの出力にしか出てこなかった時代、
庶民がコンピュータを使いはじめるよりも前にこの手のシステムは作られ始めてる。
社会の全てか全てか和暦で営まれてる以上、
和暦前提にシステムを組んだってだけだろ。
お前みたいな浅はかでバカなこと考えるのはお前だけだ。 某全国ネットに近いところの金融機関システムはちらっとさわったことがあるがそこはベースデータはもう西暦になってたな
それをまた和暦に変換するとかめんどいことをやってた
北陸銀行とかの地銀だとまあしゃあないんだろうな
>>668
うちは孫ひ孫だから子ウケに普通に言ったけど、親ウケのオバハンが子ウケに『ただデータをコピーするだけでしょ?』って見積りの1/10の金額を口にした
チョーデカい企業のオバハンがこんなこと言うんだって怒りとか呆れ通り越して興味深かったわ 珍獣見た感じ
子ウケのにーちゃん、今日徹夜だろなかわいそーw もうソフトウエアは論理的思考のできない日本に作らせちゃ駄目
今日試してくれないかな
バグってたら下っ端デスマーチ確定なんだが
社会の隅々まで昭和で動いてた話なんか分かる
任天堂のディスクシステムまで内部では昭和で動いてたみたいだし
配信日とか書き込み日とかが昭和だったみたい
改元にも対応しなかったらしい
業界のイメージ的には黎明期から西暦で動いてそうなのに
>>708
最初の報告が浜銀だったらもうちょい騒がれてたかもしれん。
印象の力すごい >>708
「北陸」という名称だけど実質影響があるのは富山県内だけだもん
そりゃあねえ if (num == 1)
{
s = "明治";
}
else if (num == 2)
{
s = "大正";
}
else if (num == 3)
{
s = "昭和";
}
else
{
s = "平成";
}
>>74
金融機関はアホだから元号で基幹系作ってるよウチもな >>713
文字列だからだろ
ちょっとは考えろよw >>674
じゃあ皇紀にしとけやガチガイジ
って思うんだけどなw 残高も平成元年に戻ればリッチになる人もいるのだろうな
>>719
田舎だと地銀のネットワークにのっけてもらうコンビニATMはそこそこある
ローソンもセブンとかもそんなんでやってるぞ ■ このスレッドは過去ログ倉庫に格納されています