パスワードを忘れた? アカウント作成
6379863 story
UNIX

2038年問題まであと8億秒 82

ストーリー by hylom
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パーティはあるのでしょうか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by iwakuralain (33086) on 2012年09月13日 9時04分 (#2230542)

    出来上がったもののテストしてたら2038年問題に遭遇しましたよ。
    会員の有効期限が30年くらいのものがあって、それをテストしたらエラー発生。
    いろいろと原因を調べていくとどうやら30年有効のはずなのになぜか19xx年までの有効年月と判断されて弾かれてました。

    対応してるところは大丈夫と思いますが、長いスパンで見るシステムなんかは(保険とか)気にしてたほうがいいんでしょうね。

    # さすがに引退はしてると思うけど、25年後に自分のプログラムを修正する可能性を考えたら今のうちに対応しといたほうがいいんだろうな・・・

    • Windows と Linux で同じソースのプログラムでソフト作ったら、
      それぞれで作ったセーブデータに互換性がなくて悩みました。

      調べたら、構造体のサイズが違っていたのが原因でした。
      ヘッダ調べたら、リナックス側の time_t の定義が __time64_t デフォルトになってました。
      つまり、新しい gcc ライブラリでプログラム組めば対応済みってことかな?

      親コメント
      • by Egtra (38265) on 2012年09月13日 18時54分 (#2231096)

        Windows側、Visual C++も2005からtime_tは64-bitがデフォルトになりました。ソースコードがあれば、新しい環境でコンパイルすればとりあえずは良いわけです(ほかで指摘されているように、お行儀の悪いコードでなければ)。

        親コメント
        • 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の型変換で値が変わらないことは保証されてるし。

          親コメント
    • by SteppingWind (2654) on 2012年09月13日 11時20分 (#2230660)

      保険関連では, 長期の契約に対応するために, 戦前から皇紀で記述していたのを引き継いだため, 2000年問題の影響を受けなかったとこがある. なんて, 嘘かマコトかよく分からない話がありましたが, この場合も皇紀2700年が2040年なので, そろそろ射程距離ですね.

      親コメント
    • by Anonymous Coward

      ルート証明書なんかも鬼門ですね。
      2038年を超えているものだけエラーになるのでなかなかわかりにくいです。

  • by duenmynoth (34577) on 2012年09月13日 6時30分 (#2230499) 日記
    2000年問題だって1999年まで放置したんだし、ギリギリまで放置でいいっしょ

    今すぐ何かしなくても勝手になんとかなってるかもしれないしね~

    #って人ばかりじゃないことを祈りますが
  • by Anonymous Coward on 2012年09月13日 9時13分 (#2230545)

    GPSの1024週である2019年4月7日かな?

    前回は1999年だったが、今となっては普及範囲が
    広すぎるほど。

  • 長期のローン計算システムや、6ヶ月分の定期券を扱う
    システム、航空機の予約などで扱う日付型で問題が起
    こる可能性があります。

  • by Anonymous Coward on 2012年09月13日 6時54分 (#2230502)

    バグというか時限爆弾を仕込んでおいて、それをチェック・修正しますよといって金を取る

    のか、君たちは。
    とか言われそう。

    • by quililila (23086) on 2012年09月13日 8時13分 (#2230521) 日記

      なにを甘っちょろいことを。
      2000年問題の時は時刻なんて扱ってないシステムですら2000年問題対策でお金を取っていた業界ですよ。
      そんなことを言われてもちゃんとお金を取ってきます。

      社会的に盛り上がってくれればこれぐらいはいける。

      親コメント
    • by Anonymous Coward

      こちらが原因を作ったわけではないのだから、
      そちらで何とかしてくれるんですよね?

      くらいは言われるでしょう。

  • by Anonymous Coward on 2012年09月13日 7時53分 (#2230513)

    2038年で暦がなくなっていてそこで世界が終わるんですとか言っておけば一般向けの周知はバッチリでしょう。
    # ねーねーマヤ暦の終わりはどうなったのー?

  • by btr (33574) on 2012年09月13日 8時24分 (#2230527)

    次は、2^29(5億3687万0912)秒、2^28(2億6843万5456)秒、2^27(1億3421万7728)秒と注意喚起すれば。

  • by Anonymous Coward on 2012年09月13日 9時58分 (#2230584)

    2038年問題が起きるのは2038年1月19日なのです。
    これに伴い毎年1月19日はIT技術者の日とし、感謝の意を表しましょう。
    そして、普段残業や休日出勤が多い彼らがこの日に逃げ出しても有給休暇を取っても良い様に計らいましょう。

  • by Anonymous Coward on 2012年09月13日 7時11分 (#2230504)

    OSの内部的な時刻の表現は64ビット化が進んでいて西暦3000億年まで大丈夫になりつつあるようです。
    スクリプト系言語は32ビットとして扱ってなければそのままでも大丈夫なような。
    データベースのカラムが32ビットだったらダメですけど。time型カラムとかdatetime型カラムは対応が進んでそう。

    それにしても動作確認が大変そうですね・・・

    • by SteppingWind (2654) on 2012年09月13日 10時56分 (#2230635)

      実際のところ, 抽象的な時刻型で記述してあるプログラムについては, それほど大きな問題にはならないのではないかと思います.

      問題なのは時刻型を32bit符号付き整数という前提でcastして取り扱っていたり, あるいはcastさえせずにwarning無視で使っていたりするケースじゃないでしょうか. そういう類のプログラムだと, 事は時刻型だけにとどまらず他の各種のデータについても同様の潜在バグを抱えていることがままあります. そうすると, 今日的なチェックの厳しいコンパイラだとコンパイルを通らない. コンパイルを通っても, そもそもバグを抱えていたのがたまたま動いていただけなので, まともに動きようがない. 結果としてプログラムの直しようもなく, 旧来のバイナリをそのまま使わざるをえない. ってところかと.

      Cなんかが業務システムで使われるようになって, そろそろ30年ってところですから, ソースが紛失したなんてケースも少なからずありそうな.

      親コメント
    • by Anonymous Coward

      実はVARCHAR2だから問題ない所が多かったり

      • by Anonymous Coward

        やめて。

        この間も、何故かほぼ全てのフィールドがTEXT型のPostgreSQLデータベースで悩んだよ…。

  • by Anonymous Coward on 2012年09月13日 7時52分 (#2230512)
    対応済み?
    • NTP (名古屋トヨペットでないほう) の秒の表現は64ビットだが、Epochが1900年1月1日なので、2036年問題を起こす。一応対策済み、といえば済み。#2230560に言及されているとおり。
      • by Anonymous Coward

        #2230560のコメントってどれ? そんな番号のコメントは(現時点で)ないみたいだけど。
        # まだ何の対策もしていないということかー!

      • by Anonymous Coward

        64ビットじゃなくて、符号なし32ビット。

  • by Anonymous Coward on 2012年09月13日 9時51分 (#2230578)

    そんな先まで今のシステムがそのまま使われているなんて、そんな事があるはずが無い!
    入れ替えるときにちゃんと対策されたプログラムに変わってるさ!

  • by Anonymous Coward on 2012年09月13日 9時58分 (#2230582)

    >「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とする

    「とりあえず31ビットの二進数の桁あふれ」という説明で良いんじゃないの?
    残りの1ビットはどこへいった?と聞いてくる人がいたら、それは符号ビットだよと答えれば良いし、そう質問する人はそういう説明を理解出来る人だろうからそれでいいでしょ

    • by s02222 (20350) on 2012年09月13日 11時14分 (#2230652)
      実はそれに加えてプログラミングに関する専門知識が必要です。C言語標準の場合、符号付整数の桁あふれは、未定義動作なので。

      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のオーバーフローが注目を集めたら、「これが未定義動作ってひどくね?」という方向へも話が飛び火したりしないのかな。
      親コメント
    • by Anonymous Coward on 2012年09月13日 10時29分 (#2230611)
      > 「とりあえず31ビットの二進数の桁あふれ」という説明で良いんじゃないの?

      その説明で一般大衆、経営者、政治家などに通じないから懸念があるわけでしょ。ここを見てるような人にとってはそりゃ常識の範囲内でしょうけど、「31ビットの二進数」ってあたりですでに「ある程度の専門知識」ですから。
      親コメント
      • by Anonymous Coward

        そんな人にはぜひ片手で31まで数える方法を教えてあげてください
        #まあ、31人以下の人員点呼などをする時には役立つだろう。。。。。。。。

    • by Anonymous Coward

      円周率およそ3世代もn進数を学校で習ってたっけ?

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...