2038年問題まであと8億秒 82
ストーリー by hylom
8億秒と言われてもよく分からない…… 部門より
8億秒と言われてもよく分からない…… 部門より
rm -fr 曰く、
/.Jなら詳細な説明は省いても大丈夫と思われる2038年問題の発生まで、日本時間9月13日6:00（UTC9月12日21:00）にてあと8億秒となった（カウントダウンページ）。上記wikipedia記事によると、
- 2000年問題はアプリケーションレベルでの修正が可能であったが、この問題は現在普及しているC言語処理系やOSのAPIといったシステムの深いレイヤに潜む問題である。
- 「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とするので、一般大衆、経営者、政治家などの理解と関心を得にくい可能性がある。
- 2000年問題のように暦年の変わり目というキリのよいときに地域の標準時に応じて順次に問題の時刻が世界を巡るのではなく、ごく中途半端な時刻に世界同時に一斉に問題の時刻が訪れるので、もし問題が生じた場合は対応するための人的資源の確保がより困難となる可能性がある。
と、2000年問題より深刻だが一般人への周知が難しいとされており、/.Jなどで記念日的に取り上げてみる試みも悪くないかとタレこんでみました。
Unix time「1234567890」を祝うサイトとパーティのようなtime_tパーティはあるのでしょうか？
こないだ遭遇した (スコア:5, 興味深い)
出来上がったもののテストしてたら2038年問題に遭遇しましたよ。
会員の有効期限が30年くらいのものがあって、それをテストしたらエラー発生。
いろいろと原因を調べていくとどうやら30年有効のはずなのになぜか19xx年までの有効年月と判断されて弾かれてました。
対応してるところは大丈夫と思いますが、長いスパンで見るシステムなんかは（保険とか）気にしてたほうがいいんでしょうね。
# さすがに引退はしてると思うけど、25年後に自分のプログラムを修正する可能性を考えたら今のうちに対応しといたほうがいいんだろうな・・・
Re:こないだ遭遇した (スコア:2)
Windows と Linux で同じソースのプログラムでソフト作ったら、
それぞれで作ったセーブデータに互換性がなくて悩みました。
調べたら、構造体のサイズが違っていたのが原因でした。
ヘッダ調べたら、リナックス側の time_t の定義が __time64_t デフォルトになってました。
つまり、新しい gcc ライブラリでプログラム組めば対応済みってことかな？
Re:こないだ遭遇した (スコア:2)
Windows側、Visual C++も2005からtime_tは64-bitがデフォルトになりました。ソースコードがあれば、新しい環境でコンパイルすればとりあえずは良いわけです（ほかで指摘されているように、お行儀の悪いコードでなければ）。
Re:こないだ遭遇した (スコア:1)
2000年問題が問題になったのは、DBなんかで年を二桁固定にしてたのが多かったからですよね。外部仕様の変更は大仕事です。対応修正の反映更新を全システム同時に行う必要があるし。
一方、2038年がそんな外部仕様レベルで問題になるのは、通信プロトコル、ファイル入出力、DB定義なんかの外部仕様で、32bit型整数でUNIX time をそのまま使っていた場合、なわけですが、そんなことをする該当例はそれほど多くないと思います。DBなら普通はDate型か年月日時分秒にするだろうし。
それなら、あとは時刻を time_t 型として適切に処理するように、という内部処理的な問題なので、外部仕様は変えないまま、順次対応していくことが可能です。
time_t が 64bit になったことで、コード無修正の再コンパイルだけで対応できる例も多いでしょう。time_t ではなく int 型を使っているような古くさいコードがあったとしても、time_t に変更することはそれほど難しくないと思います。
かなりのソフトランディングになるんじゃないかなぁ。
UNIX time 32bit整数を外部仕様に使ってたとしたら…ご愁傷様です。
とりあえずは、符号無し32bitにして2106年までお茶を濁すのかなぁ…
C言語だと、符号付64bit→符号無32bitの型変換で値が変わらないことは保証されてるし。
皇紀2700年問題 (スコア:1)
保険関連では, 長期の契約に対応するために, 戦前から皇紀で記述していたのを引き継いだため, 2000年問題の影響を受けなかったとこがある. なんて, 嘘かマコトかよく分からない話がありましたが, この場合も皇紀2700年が2040年なので, そろそろ射程距離ですね.
Re: (スコア:0)
ルート証明書なんかも鬼門ですね。
2038年を超えているものだけエラーになるのでなかなかわかりにくいです。
2037年になってから考えればいいや (スコア:4, おもしろおかしい)
今すぐ何かしなくても勝手になんとかなってるかもしれないしね～
＃って人ばかりじゃないことを祈りますが
Re:2037年になってから考えればいいや (スコア:1, 参考になる)
2000年問題は1999年まで放置してたわけではないですよ。
某社のケースでは具体的なアクションは３年前から、対策プロジェクト自体の発足は５年前です。
Re:2037年になってから考えればいいや (スコア:1)
今のうちに関連商標権を抑えるとか、うまい対策思いついたら特許をとっておくとか。
#すでにやってる？
Re: (スコア:0)
どうすっかな～俺もな～（主体性皆無）
Re: (スコア:0)
その時は一線を退いてるからどうでもいいや
※ある程度まとまったお金は下ろしておくべきでしょうか
Re: (スコア:0)
なるほど
２０３８年問題ってそれまでにまとまった金を用意出来ない貧乏人が勝利するって問題なんですね
# マジレスすると2038年まで生き延びる金融機関がどのぐらいあるだろう・・・
Re: (スコア:0)
既に現金が廃れてたりしてな、案外
Re: (スコア:0)
と、悠長に考えていたら2036年にこけたりして。
2036年問題 [wikipedia.org]
Re:2037年になってから考えればいいや (スコア:1)
2038年問題が2038年に起こるわけではない、2004年にすでにおきています。
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040202/139212/ [nikkeibp.co.jp]
Re: (スコア:0)
2004年に大したことなかったんだから大したことないな
次に起きる大規模日付問題 (スコア:3, 興味深い)
GPSの1024週である2019年4月7日かな？
前回は1999年だったが、今となっては普及範囲が
広すぎるほど。
Re:次に起きる大規模日付問題 (スコア:1)
GPSからNTPに流してるとことか、あるんじゃないかな？
ネットワークって怖いね。
Re:次に起きる大規模日付問題 (スコア:1)
年問題#コンピュータの時刻処理に関わる問題 [wikipedia.org]にいろいろ挙がってますよ。
事前から発生する可能性があります。 (スコア:2)
長期のローン計算システムや、6ヶ月分の定期券を扱う
システム、航空機の予約などで扱う日付型で問題が起
こる可能性があります。
IT業界的錬金術 (スコア:1)
バグというか時限爆弾を仕込んでおいて、それをチェック・修正しますよといって金を取る
のか、君たちは。
とか言われそう。
Re:IT業界的錬金術 (スコア:1)
なにを甘っちょろいことを。
2000年問題の時は時刻なんて扱ってないシステムですら2000年問題対策でお金を取っていた業界ですよ。
そんなことを言われてもちゃんとお金を取ってきます。
社会的に盛り上がってくれればこれぐらいはいける。
Re: (スコア:0)
こちらが原因を作ったわけではないのだから、
そちらで何とかしてくれるんですよね？
くらいは言われるでしょう。
IT業界的大予言 (スコア:1)
2038年で暦がなくなっていてそこで世界が終わるんですとか言っておけば一般向けの周知はバッチリでしょう。
# ねーねーマヤ暦の終わりはどうなったのー?
Re:IT業界的大予言 (スコア:3)
you は shock
Re:IT業界的大予言 (スコア:2)
マヤ暦の終わりは今年の12月21から23日ころですよー
後3ヶ月は油断できません。
まぁほんとに終われば、今年のクリスマスは中止になるので、
大変喜ばしいことかと。
#17世紀に滅んだマヤ人も2012年問題がここまで
#大きく取り上げられるとは思ってなかっただろうなぁ
Re:IT業界的大予言 (スコア:1)
違う違う. マヤ暦は仕様上はもっと先(7000年ぐらい) [nationalgeographic.co.jp]まで対応していたけど, 後になって作ったサブセットが先に広まっちゃったので, 大事になっちゃったんですよ.
どうせなら (スコア:1)
次は、2^29(5億3687万0912)秒、2^28（2億6843万5456）秒、2^27（1億3421万7728）秒と注意喚起すれば。
アキレスと亀 (スコア:2)
あと2^-1秒、2^-2秒、2^-3秒……と考えればいつまでたっても0秒にならないから大丈夫！
Re: (スコア:0)
まだ2^16秒もある……って思えてしまいそう
提案 (スコア:1)
2038年問題が起きるのは2038年1月19日なのです。
これに伴い毎年1月19日はIT技術者の日とし、感謝の意を表しましょう。
そして、普段残業や休日出勤が多い彼らがこの日に
逃げ出しても有給休暇を取っても良い様に計らいましょう。意外と大丈夫？ (スコア:0)
OSの内部的な時刻の表現は64ビット化が進んでいて西暦3000億年まで大丈夫になりつつあるようです。
スクリプト系言語は32ビットとして扱ってなければそのままでも大丈夫なような。
データベースのカラムが32ビットだったらダメですけど。time型カラムとかdatetime型カラムは対応が進んでそう。
それにしても動作確認が大変そうですね・・・
Re:意外と大丈夫？ (スコア:2)
実際のところ, 抽象的な時刻型で記述してあるプログラムについては, それほど大きな問題にはならないのではないかと思います.
問題なのは時刻型を32bit符号付き整数という前提でcastして取り扱っていたり, あるいはcastさえせずにwarning無視で使っていたりするケースじゃないでしょうか. そういう類のプログラムだと, 事は時刻型だけにとどまらず他の各種のデータについても同様の潜在バグを抱えていることがままあります. そうすると, 今日的なチェックの厳しいコンパイラだとコンパイルを通らない. コンパイルを通っても, そもそもバグを抱えていたのがたまたま動いていただけなので, まともに動きようがない. 結果としてプログラムの直しようもなく, 旧来のバイナリをそのまま使わざるをえない. ってところかと.
Cなんかが業務システムで使われるようになって, そろそろ30年ってところですから, ソースが紛失したなんてケースも少なからずありそうな.
Re: (スコア:0)
実はVARCHAR２だから問題ない所が多かったり
Re: (スコア:0)
やめて。
この間も、何故かほぼ全てのフィールドがTEXT型のPostgreSQLデータベースで悩んだよ…。
NTPって (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
#2230560のコメントってどれ? そんな番号のコメントは(現時点で)ないみたいだけど。
# まだ何の対策もしていないということかー!
Re: (スコア:0)
Re: (スコア:0)
#2230510のリンク先を見たけど対策なんてどこにも書かれていないような。
Re: (スコア:0)
64ビットじゃなくて、符号なし32ビット。
Re:NTPって (スコア:1)
大丈夫大丈夫 (スコア:0)
そんな先まで今のシステムがそのまま使われているなんて、そんな事があるはずが無い！
入れ替えるときにちゃんと対策されたプログラムに変わってるさ！
ある程度の専門知識を必要とする (スコア:0)
＞「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とする
「とりあえず31ビットの二進数の桁あふれ」という説明で良いんじゃないの？
残りの1ビットはどこへいった？と聞いてくる人がいたら、それは符号ビットだよと答えれば良いし、そう質問する人はそういう説明を理解出来る人だろうからそれでいいでしょ
Re:ある程度の専門知識を必要とする (スコア:4, 参考になる)
time_t t = foo + bar;
などとやった場合、コンパイラは「foo + barは、MAX_INT以下である」という前提でコンパイルしても良いことになっています。 「C言語 未定義動作 バグ」ぐらいでWebを検索するといろいろ具体例が出てきますが、例えばこれ [intransient.info]とか。
time_t tomorrow = now + 60*60*24; //現在時刻nowから、丁度1日後の日時を求める
if(tomorrow < now) {// 足してるのに小さくなっていると言うことはオーバーフローしたはず! 2038年問題!
//対処コード
}
とか書くと、コンパイラは「正の整数を足してるんだから、値が小さくなるはずがない。C言語の規約で、オーバーフローするような計算はしちゃいかんことになっているから、オーバーフローが原因で負になる可能性も無い。よって、このif文の条件は常に非成立。if文の中身と条件判定を削除して高速化できるぜやっほー」、とやっても良かったりします。
なので、ぱっと見に分かりにくいバグをはらんでたり、対処したつもりが何故か利かなかったりする可能性があります。 ややこしいので「その最適化はするな」というコンパイラオプションもあるので、とりあえずそれをONにして回った方がいいでしょうね。
# ここまでintのオーバーフローが注目を集めたら、「これが未定義動作ってひどくね?」という方向へも話が飛び火したりしないのかな。
Re:ある程度の専門知識を必要とする (スコア:1)
まさに「エラー」ではなく「例外」ですからね.
「例外」を意識するのって組み込みやドライバでは普通だと思いますが, アプリケーションプログラムだと, せいぜい浮動小数点例外ぐらいでしょうか.
Re:ある程度の専門知識を必要とする (スコア:1)
その説明で一般大衆、経営者、政治家などに通じないから懸念があるわけでしょ。ここを見てるような人にとってはそりゃ常識の範囲内でしょうけど、「31ビットの二進数」ってあたりですでに「ある程度の専門知識」ですから。
Re: (スコア:0)
そんな人にはぜひ片手で31まで数える方法を教えてあげてください
＃まあ、31人以下の人員点呼などをする時には役立つだろう。。。。。。。。
Re: (スコア:0)
円周率およそ3世代もn進数を学校で習ってたっけ?
Re:ある程度の専門知識を必要とする (スコア:2)