世田谷区の通知書類で「平成3元年」との誤表示、和暦の一の位が「1」だった場合「元」に変換する処理だった 117
ストーリー by hylom
10年に一度発生する不具合 部門より
10年に一度発生する不具合 部門より
東京都世田谷区が区民に送付した「平成30年度世田谷区私立幼稚園等保護者交付決定通知書」で、日付が「平成3元年」と表記される不具合があったという。実害はないとのこと（日経xTECH）。
原因は印刷業者のソフトウェアの不具合。このソフトウェアでは、和暦の1の位が「1」だった場合に「元」に変換する処理が組み込まれていたという。テストの際に使用したデータがダミーデータだったためにテスト時に問題が発覚しなかったそうだ。
コードチェック (スコア:2)
レビューアの目は節穴か？
それとも仕様通りなのか？
Re:コードチェック (スコア:1)
その二つの疑問は背反するとは限らない。両立することもありうる。
// おそらくほかにも無矛盾な候補の可能性は山ほど…
Re:コードチェック (スコア:1)
レビュアーなんて存在しないという可能性もある（うちの会社はいないときもたくさんある笑）
Re: (スコア:0)
このクソコードを書いたのは誰だあっ！！
Re:コードチェック (スコア:2)
2000年問題で同じような経験をしたから。
Re:コードチェック (スコア:1)
テスト屋です。（実話）
Re:コードチェック (スコア:1)
このバグに関して言うならそれはあり得ない。
MS嫌いな人がいるのは別に良いけど、
無理筋で誹謗中傷する奴は批判的な人からも肯定的な人からも顰蹙買うぞ。
Re:コードチェック (スコア:2)
取引を切るテキトーな言い訳をそのまま信じているのかも…
Re:コードチェック (スコア:1)
MicrosoftのUpdateが配布されたらすぐ適用される油断だらけのオフィス環境
云々という補足説明があればいいのになあ。
そういう不適切アップデートモジュールのによってナイーブな職場は阿鼻叫喚
などと悪意ある紹介をしてくれたほうが背景事情が伝わったのでは?
歴史に名を残す仕事 (スコア:1)
プログラマをやってると「あの家電の液晶画面は俺が作ったんだよねー」的な昔話ができるんですが
「バグ作り込んだら新聞に載っちゃったよー」的な話も一度ぐらいあっても良いなぁと思いました．
和暦の1の位が「1」だった場合に「元」に変換する処理なんて，ネタとして面白すぎます．楽しい職場だと思いませか？
私も愉快なバグを作って歴史に名を残したい．
Re:歴史に名を残す仕事 (スコア:2)
>和暦の1の位が「1」だった場合に「元」に変換する処理なんて，ネタとして面白すぎます．楽しい職場だと思いませか？
なんで「和暦の1の位」だけ見ちゃうんでしょうね。
素直に 和暦の値自体が "1" であれば "元" に置き換える でいいのに。
if($koyomi = 1){ $koyomi = "元";}
Re:歴史に名を残す仕事 (スコア:1)
ウチの若いプログラマは日付（和暦）をいぢるロジックにおいて「年は二桁」として扱うコードを書いた。そして改元対応による検証時にそれが発覚した。
1桁の年を経験したことがなかったことが原因らしいが，月とか日とか時とか，いくらでも類推できる材料はあるだろうに。
Re:歴史に名を残す仕事 (スコア:1)
「これは友人の・・・あくまで私の友人の話なのだが。」
わかります。
超長期国債 (スコア:1)
超長期国債の場合，発行時の償還期限が元号3桁になる場合がありそうだけど．
Re:歴史に名を残す仕事 (スコア:1)
s/1年/元年/g; とか(相当する各プログラミング言語の機能で)やってたんじゃないですかね。
Re: (スコア:0)
ソースコードの、"平成31年"という文字列に変更されて以降の処理の部分しかいじれなかったので、s/1年/元年/gを入れた、とか?
Re:歴史に名を残す仕事 (スコア:1)
なるほど元を触れない場合もありますね。
役所の処理系とかだと、かなりこだわった仕様や制約もありそう。
Re:歴史に名を残す仕事 (スコア:2)
油断すると、21th, 22th, 23th をやっちゃう罠。
#「トゥウェンティーファースト」って読めば間違えないんだろうけど、
#「にじゅういちす」って読んでたりするので気づきにくい…
Re:歴史に名を残す仕事 (スコア:2)
自分が見たのは逆だ。最後の桁しか見てないので、
11st,12nd,13rd
Re:歴史に名を残す仕事 (スコア:1)
命令されてバグの名目で連チャン組んだら、それを命じた役員さんが警察に手配されて逃げたって事なら。
Re:歴史に名を残す仕事 (スコア:1)
惜しむらくは、「1の位が」限定で実装されていることと、
今年が、平成11年ではないことです。
# koyomi= koyomi.Replace('1', '元')
# としておけば、平成元元年とか見ることができたか、
# 帳票の表示範囲を超えた結果、平成元年と表示される結果になっただろうに
Re:歴史に名を残す仕事 (スコア:1)
まさか…エクセル方眼紙？
平成20年ごろ作って (スコア:1)
#まぁ別に無償依頼してもいいけど無償と有償でこれだけ変わることだけ覚えておいてくれよなっていうテンプ (スコア:1)
とりあえず、ググったら出てきたURL
https://thainokoe.com/taiwan-hanno/compare-free-vs-paid-illust/
11年や21年の時はどうしてたんだろう。 (スコア:0)
22年以降に導入されたシステムなんだろうか。
Re:11年や21年の時はどうしてたんだろう。 (スコア:2)
平成元年以降に導入されて、元々元年表示が出来なかったが、
今回の令和対応で盛り込んだ結果…という可能性もありますね。
Re: (スコア:0)
なに考えてんだと思ったがこれか…
5月元日 (スコア:0)
わりと違和感がない
Re: (スコア:0)
朔日とか晦日とかの伝統は途切れているが。
＃「元日」は正月限定だ。
＃生前退位で1月1日付で新元号にしてくれたら、「××元年元日」付けの年賀状が出せたのに。
＃現行ルール上、かなり難しい気がするけど。
Re:5月元日 (スコア:1)
現行法上踰年改元は禁止されてない気がする。
元号法には「元号は、皇位の継承があつた場合に限り改める。」としかないんで
いつ改めるかまでは践祚後ということしか決まってないと思う。
Re:5月元日 (スコア:1)
法律学的には必ず改めなければならないわけではありませんよ。皇位継承があったのに政府が改元しなくても合法です。
発送前に気付かなかったのか (スコア:0)
対象世帯に約1万通を発送したという。
実際に刷り上がったものの確認とかしないものなんでしょうか？
プライバシーの関係？
Re:発送前に気付かなかったのか (スコア:2)
刷り上げてしまったものを確認した上で、あえて発送した可能性。
実害はないんだからそれが合理的。
クレームがあったら、適当に謝罪しとけばいいんだから。
これをもし廃棄して再出力とかしてたら、むしろそのほうが非難されるべき。
もったいないがな。
Re: (スコア:0)
袋に詰めるまで自動だからチェックすらしないのでは。
Re: (スコア:0)
確認を行う担当者が割りふられていなかったため、確認ができてませんでした
＃役所ではよくある事
面倒くさくない？ (スコア:0)
本来期待される「和暦が「1」だった場合に「元」に変換する処理」より
「和暦の1の位が「1」だった場合に「元」に変換する」の処理の方が面倒くさそうなんだけど？
（それも 31年→元年 ではなくて、 31年→3元年 なんて･･･）
なんで、あえて面倒くさい処理にしたんだろう？
実は、「1を全て「元」に変換する」処理だったんではないだろうかと邪推してしまう。
Re:面倒くさくない？ (スコア:2)
固定長レコードなんでしょ。
したがってCOBOLと推測した。
Re:面倒くさくない？ (スコア:2)
「令和100年問題」の予感
Re:面倒くさくない？ (スコア:2)
Z9を置き換えるならともかく
Re:面倒くさくない？ (スコア:2)
Re:面倒くさくない？ (スコア:1)
"平成 １年"を
"平成 元年"に変換する場合、
4文字目を'１’から'元'に変更するだけなら4文字目だけをチェックする方が簡単ですよ。
"平成１１年"や"平成２１年"を例外にするなら3文字目のチェックも必要だし。
Re: (スコア:0)
つまり元元年の可能性もあったと!？
Re: (スコア:0)
すでにそこに至った時点で文字列だったんでしょう。
で、10年以降の上位桁が誤爆しないように"1年"を"元年"に置き換えたと。
Re: (スコア:0)
文字列だとしても
”01”or" 1"を元にするんじゃいかんのか？
COBOL固定長でも2桁文字列の比較ぐらいできるだろ。
なぜ下位１桁だけで判断する必要がある？
Re:面倒くさくない？ (スコア:1)
(明治|大正|昭和|平成|令和)1年を検索して、(括弧の中のマッチしたもの）元年 に変換するような。
まあ明1年とかやられたらアレですが。
-- To be sincere...
令和３１年 (スコア:0)
っていうのも出現したし。
次はどういうネタが出るか。
平成３１年５月ってのはありそう。
令和３１年４月生まれとかもありそう。
あるいは令和元年４月とか。
Re: (スコア:0)
今回のバグは、改元と関係ないようですよ。平成22年以降に使われだしたシステムで、平成31年でははじめて使われたのではないでしょうか。
原因は改元のシステム対応と別だった
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/04724/ [nikkeibp.co.jp]
Re:令和３１年 (スコア:1)
この修正をした人は平成は31年になる前に改元すると思ってたんでしょ。
Re: (スコア:0)
「平成３１年５月」は現時点では正しい表記、
「令和３１年４月」も将来的にはあり得る。
経産省の御触書 (スコア:0)
https://www.meti.go.jp/policy/it_policy/kaigen/faq.html [meti.go.jp]
がとっとと出てりゃ何もする必要もなかったのにね。