  |
はてなキーワード: 2038年問題とは
【新元号】改元のシステム改修で慌てるシステム屋は「無能」とのこと - Togetter
最初に一言書いておくと、元号がシステムに最も絡んでいるであろう金融機関とか官公庁とか、そういうとこのシステムって想像以上に複雑怪奇に絡み合った化物みたいにどでかいやつが多くて改修めちゃくちゃ大変だと思うので、あんまり外野から勝手なこと言わんといてあげてください。
あんまりないと思うけど、今書いた通り官公庁とか金融機関は困るんじゃないですか。流行りのふるさと納税とかやったことないですか？ あれのワンストップ特例申請見るだけでも、どこで元号使われてるかわかりますよね。
言いたいことはわかる。わかるけど、問題はそこではないと思う。仮に改元に対応可能なシステムを組んでいたとしても、そのシステムはこれまでに改元を経験していない。つまり実際に改元する際の手順を確認する必要があるし、その影響範囲を見極めなくちゃいけないし、改元作業のテストが要るし、改元当日のためのリハーサルが要るし、そのための業務調整やら休日出勤やら何やらが発生するわけで、いずれにせよ「平成」と書いてあったところを「hogefuga」と書き換えて半日ぐらいでハイ終了、みたいな話ではない。
というか、システムなんて想定外がヤマのようにあるのが常だろう。IPv4が枯渇するなんて想定されていなかったし、西暦2000年も想定されていなかったし、今後も2038年問題なんてのも控えてる。そんなもんだろ。システムって。
言いたいことはわかる。が、今回に関しては「事前に新元号が通知される」からこそ問題なんだと思う。
昭和→平成のときのように、突然元号が変わったとしよう。その場合、突然なので誰もすぐには対応できない。その時点でみんなが手遅れだ。だからこそ、SEはお客さんと調整しやすいんじゃないだろうか。すみません、半年かかります、1年はかかります、だからそれまでは暫定で平成使いましょう、西暦使いましょう、みたいな。まぁ、そうも行かない人たちはデスマるんだろうし、そういった負担や混乱を鑑みて、今上天皇は「生前退位」の意向を示したんだったと思うけど。
今回は事前に改元の日程がわかっている。2017年12月に閣議決定しているので、1年半近い猶予があった。そうすると当然、改元当日までに対応しようと誰もが思う。早く新元号を発表してもらって、悠々と対応を終えておきたいと思うのが人情だ。それなのに、新元号の発表は1か月前だと言い始めた。だからみんな憤っている。
もちろん、1か月前まで何もしないわけじゃなくて、仮の文字列を使って改修やテストは進めるだろう。しかし、最終的には正しい新元号がきちんと画面に表示されるか、帳票に印刷されるか、そういう確認が必要になる。元号を使うシステムなんて、公的機関や金融機関が多いだろうから、尚更チェックは厳しいだろうし、役所にある様々な種類の書類とか申請書、あれ全部新元号が表記されてること多分チェックしますよ。んでチェックした帳票や申請書を全国にあらかじめ配送しておいて5月1日から使ってもらうとか、そういう手配も必要なわけで。そういうことに1か月しか使えない、って結構ぞっとしない話じゃないですか。
言いたいことはわかる。でも、そんな簡単な話じゃない。
例えば。何らかのデータを、元号による日付入りで1000社に販売している会社があるとしよう。その会社が改元対応を行う。すると、そのデータを受信している1000社でも、受信後のデータ処理やらバッチ処理やらに影響が出ることになる。システムというのは、単体で動くものではなくて、複数が連関して動く。だから1箇所の変更が、その末端や連携先にも影響を及ぼすことが多い。複数社が関わるシステムの場合、各社の都合もあるので、2回に分けてシステム変更のリハーサルをやりますだとか、そういことだってあり得る。それを果たして1か月のうちに全部終えられるのだろうか。
無理でしょ。銀行の真ん中とかメインフレームだぞ。あれがインターネットにでも繋がってると思ってんのか。
疲れたからこのへんで。特に3つ目が重要かなと思っていて、本来なら1年半あったはずの猶予がわざわざ1か月に縮められるあたりが怒りを呼んでいるんじゃないでしょうか。わざわざ短い納期で焦ってやって失敗したら、それまたみんな叩くんでしょ？ 陛下のおことばにも、国民の暮らしへの影響が言及されていてとてもありがたい話なのに、なんで「短納期でも問題ないだろ」ってその国民から蹴り入れられなくちゃなんないんですかね。
1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っている物があったとされ、そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1024週後にあふれて0に戻る。
年数を下2桁だけで処理していたシステムや、2000年を平年(閏年ではない)と誤解したシステムに問題が起こる。
1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。
2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。
潜在的なバグが発覚した。シチズン電波時計やソニーのゲーム機「プレイステーション3」(閏年処理)、オーストラリアのクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2048週後にあふれて0に戻る。(10ビットでは2回目)
1930年 - 2029年を下2桁で表現しているシステムに問題が起こる。同様のものに2050年問題や2070年問題などがある。
1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。
Unixなど。1970年1月1日0時(Unix epoch)からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステムに問題が起こる。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。(10ビットでは3回目)
HFSのタイムスタンプは2040年2月6日までしか取り扱えない。
System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。
2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。
1950年 - 2049年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2070年問題などがある。
1970年 - 2069年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2050年問題などがある。
FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後(2079年12月31日)までしか正常動作しない。
2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステムに問題が起こる。
FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。
更新されたGPSは内部処理で週数を13ビットで管理しており、この頃にあふれて0に戻る(正確な日時は未定)。
2286年問題-2286年11月20日17時46分40秒に起こる。原因は、2001年問題と同じ。
Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。
http://ja.wikipedia.org/
未来年表 : 生活総研
http://seikatsusoken.jp/futuretimeline/
http://www.tanken.com/yosoku.html
みんなが望む方向に未来は変わっていくのかも、と思ったため。
