広島市で、ITシステムの不具合によって2019年（令和元年）生まれの乳幼児を西暦0年生まれと誤認し、誤って高齢者向けの書類を送付するトラブルが発生した（読売新聞、日経xTECH、ハフィントンポスト）。問題のシステムは令和元号に対応済みで、本来は2019年6月より対応済みシステムを運用させるはずだったが、システムを開発したNECが運用開始時期を誤って2019年7月に設定していたという。これにより、本来は令和元号に対応済みのシステムで対象者を抽出するはずが、実際には対応前のシステムで処理してしまい問題が発生したそうだ。
対応時期の問題ではなく設計の問題では (スコア:5, おもしろおかしい)
未対応の元号を入れたら西暦 0 年扱いになったってことは、
if (gengo == "大化") {
...
} else if (gengo == "平成") {
...
} else {
seireki = 0;
}
という実装だったってことよね？ これは例外吐いてエラー停止すべき状況なのでは。
Re:対応時期の問題ではなく設計の問題では (スコア:2)
６４５年生まれ以前はどうするんだ！
Re: (スコア:0)
その存在どう考えても人間ではないので、住民票作れませんから問題ありません。
Re:対応時期の問題ではなく設計の問題では (スコア:2)
確かに日本の場合宝亀5年（774年）生まれが最長ですもんね。
＃危うく、ライバルの名前に変換しかけた。
Re:対応時期の問題ではなく設計の問題では (スコア:3)
広報大使には発行されている [blogspot.com]ようです。
Re:対応時期の問題ではなく設計の問題では (スコア:1)
int seireki;
if (gengo == "大化") {
...
} else if (gengo == "平成") {
...
}
かもしれない。
Re:対応時期の問題ではなく設計の問題では (スコア:2)
Re:対応時期の問題ではなく設計の問題では (スコア:1)
鼻から悪魔！
Re: (スコア:0)
＞ if (gengo == "大化") {
吹いた。
モデ権がない、ちょっと悔しいので AC
Re:対応時期の問題ではなく設計の問題では (スコア:1)
想定してる言語がCだったら大笑いだけど
Re:対応時期の問題ではなく設計の問題では (スコア:1)
> 想定してる言語がCだったら大笑いだけど
C言語でもちゃんと動きますよ
int gengo2seireki(const char * gengo)
{
int seireki;
if (gengo == "大化") {
seireki= 645;
} else if (gengo == "平成") {
seireki= 1989;
} else {
seireki = 0;
}
return seireki;
}
const char *seireki2gengo(int seireki)
{
const char *ptr = NULL;
for (ptr = メモリ空間の先頭アドレス; ptr !=メモリ空間の末尾アドレス; ++ptr) {
if ( seireki == gengo2seireki(ptr) )
break;
}
return ptr;
}
これで
const char *taika = seireki2gengo(645);
const char *heisei = seireki2gengo(1989);
とすると "大化" と "平成"のポインタが取れるので，
gengo2seireki(taika)) は 645
gengo2seireki(heisei) は 1989
gengo2seireki("大化") と gengo2seireki("平成") は 0
という"意図した通り"の動作になります．
Re:対応時期の問題ではなく設計の問題では (スコア:1)
元のコードでも動きますが，
const char *seireki2gengo(int seireki)
{
const char *ptr;
for (ptr = メモリ空間の先頭アドレス; ptr !=メモリ空間の末尾アドレス; ++ptr) {
if ( seireki == gengo2seireki(ptr) )
return ptr;
}
return NULL;
}
の方が良いですね．
Re: (スコア:0)
> for (ptr = メモリ空間の先頭アドレス; ptr !=メモリ空間の末尾アドレス; ++ptr) {
ここで鼻から悪魔。
> gengo2seireki("大化") と gengo2seireki("平成") は 0
コンパイラーによっては同じ文字列リテラルを1つのアドレスにまとめるものがあるのでゼロになるとは限らない
Re: (スコア:0)
新システムを準備してたんだから、旧システムがそう動くのは分かってたんじゃないかな。
新システム作って開始も2019年6月で何も問題ないはずだったんだから、わざわざ旧システム側にエラー処理を追加するはずもなく(旧システム作ったところが最初から入れておけっていう話だけど、旧システムもNECなのかな)。
Re: (スコア:0)
大筋、旧システムが異常値に対して例外吐かないのが問題って話だと思ったが……
データの入力元が信用可能としてエラー処理無しだったのか、
西暦0年がエラー値なんだけど受け側でそれをちゃんとチェックしないバグだったのか、
何も考えずに異常元号で西暦ゼロになるバグだったのか、どれだろうな……
異常データ入力として止まることなく全処理走りきってるのが不思議。
和暦西暦変換以外一切元号触る処理が無かったのか…？
Re: (スコア:0)
どっかで
catch (Exception e) {}
してたとか
Re: (スコア:0)
システムが停止すると迷惑なので、スルーして走り続けさせろ。って言われるのは、よくある事。
Re: (スコア:0)
おそらく実際は先に MOVE ZERO TO SEIREKI. してるからだと思うよ。COBOL的に考えて。
STOP RUNなんてせずに警告文をDISPLAYしておしまいで、バッチのSYSOUT見て異常データがあったら後から手動で修正しちゃうのが古典的運用法じゃないか。
送られた (スコア:2)
本人はどう思うんだろう。
内容を読んでも全然理解できないし。
Re:送られた (スコア:4, すばらしい洞察)
Re: (スコア:0)
2019歳おめでとうございます！！
Re: (スコア:0)
キリスト「私の一年先輩ですね」
Re: (スコア:0)
野暮ながら、イエスの生年は西暦前4-7年頃とされている(過去に計算間違いがあった模様)。
Re: (スコア:0)
赤さん「2019年前から生きてる人間なんておるわけないやろ」
Re: (スコア:0)
そうだよね
いくら元・西暦元年産まれの転生体に送付したとしても当時と今じゃ使用言語違うだろうから読めないよね
西暦0年の時点で (スコア:1)
なにか根本的に駄目な感じがする(西暦1年の前年は紀元前1年で、0年は存在しない)
Re: (スコア:0)
駄目なのは世界（史）の方だ！
// なんか1と-1の間に0が入らないと落ち着かない
Re:西暦0年の時点で (スコア:2)
西暦0「年」が存在しないだけで、西暦0「時間」はあるんだ、と思っとけば。
紀元前から西暦に変わる瞬間、「年」の原点。
# 「年」がきれいな整数列だというのは思い込み？
Re: (スコア:0)
キリスト教のせい
Wikipediaだけど
https://ja.wikipedia.org/wiki/0#0_%E3%81%AE%E8%B5%B7%E6%BA%90 [wikipedia.org]
17世紀まで、ヨーロッパでゼロや無限を主張することは、キリスト教への冒涜であり、死刑宣告を意味した。中世ヨーロッパではゼロを悪魔の数字とみなし、ローマ法王により使用が禁じられた。1600年には、宇宙が無限であると主張した修道士のジョルダーノ・ブルーノが、異端の罪で火あぶりの刑にされている。
Re:西暦0年の時点で (スコア:1)
でも、ヨーロッパで建物の階数を数える場合は、
2階 1階 地階（0階） 地下1階（-1階） 地下2階（-2階）
だったりするんだよね。
Re: (スコア:0)
暦を皆惜して西暦０年をいれるとして、0年は今の暦の西暦１年にするの？
それとも紀元前１年？
Re:西暦0年の時点で (スコア:1)
天文学的紀年法 [wikipedia.org]では、0年＝紀元前1年、-1年＝紀元前2年、以下続く。
Re: (スコア:0)
1500年あたりまでうるう年がなかったことにして、
うるう年の+1日分をコツコツと貯めて1年分を確保する。
和暦で登録 (スコア:1)
日経xTECHの記事の一部から抜粋
悪いことは言わない。
まずは、データーベースに新しいカラムを追加して、和暦で登録されている全員の生年月日を西暦(DATE型)に変換して入れろ。そして今後は、その新しく追加した方のカラムを見て全てを判断しろ。もちろん、新規ユーザーの登録時もこの新しいカラムにデータを入れるんだ。
そうでないと、次に元号が変わった時に、またトラブるぞ。
Re: (スコア:0)
まっとうな意見なんだが、そういう意見を受け入れられるなら既にデータは整理されてる。
されてないということは・・・わかるな。
Re:和暦で登録 (スコア:2)
実際にするかどうかは関係ないな。
充分に先の将来の問題は、ただ先送りされやすい。
それだけ。
2019歳にはとても見えません (スコア:0)
どう見ても0歳。
おあとがよろしいようで。
Re: (スコア:0)
子ほめでしたっけ
まあこれに関しては事実0歳なのですが
Re:2019歳にはとても見えません (スコア:2)
あれは、数え（生まれた瞬間一つ）なので「半分」がオチ。
Re: (スコア:0)
数え年でもオチは「どう見てもただです」なんてバージョンもあるようですし、
近年演じる際には満年齢版の「どう見ても生まれていません」もあるようですよ。
Re: (スコア:0)
NECェ... (スコア:0)
これからは1000万円の新人さんが活躍してくれることを願ってます。
Re: (スコア:0)
NECもやばいと思ったから募集かけたんでしょ
Re: (スコア:0)
そんな新人さん使ってたら案件取れません
Re: (スコア:0)
無能なマネージャーを代わりに外せばコストは同じか下がるだろ。
元記事 (スコア:0)
>本来、申請書を送付する2019年6月とすべきところを、NECが誤って2019年7月と設定した
0始まりだったんでしょうねぇ
Re: (スコア:0)
if (t.tm_mon == 6) { /* お、今日から6月か */ }
みたいなコード書いたんだろうな・・・
Re: (スコア:0)
いえいえNECは0オリジンと1オリジンの処理を混在させるのが大好きです。
せめてデータフィールド毎には統一してくれ。
同じデータなのに送り先毎、送り元毎に1足したり引いたりするコード書くのは嫌だ。
#後エンディアンを混在させるのも大好き。
#16ビット単位ではビッグで、32ビットでは16ビットの塊がリトルで並ぶってのも大好き。
元請けがNECってだけで (スコア:0)
外注使ってたら開発スキルも疑わしいな
Re: (スコア:0)
そこは大して変わらないと思う