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

OpenBSD 5.5、2038年問題に対応 34

ストーリー by hylom
あと24年 部門より
camelus 曰く、

OpenBSD 5.5がリリースされました。今回のリリースでの大きな変更点は、「2038年問題への対応」となっています(SourceForge.JP Magazine)。

# /.j には逃げ切れる方もいらっしゃると推察しますが…

2038年問題とは、1970年1月1日午前0時0分0秒(UTC)を起点としたUNIX timeが、2038年1月19日3時14分7秒で32ビットで表せる上限を超えてしまうという問題。OpenBSDではUNIX timeを扱う型(time_t)を64ビット化することでこの問題を解決している。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by KAMUI (3084) on 2014年05月07日 7時53分 (#2595310) 日記
    なんて非道い(笑)

    今回のリリースソングは「Wrap in Time [openbsd.org]」ですぞ。
  • NetBSD は 6.0 から既に全 arch で 64bit time_t になっていますが、世の中、time_t = long 決め打ちとかなソースがまだまだあるので、それらについて対応していくという地道な作業が続きます。演算とか入出力とかも。time_t = 64bit という決め打ちも、まだそうなっていないOSがあるのでダメです。
    • まぁ主な問題は各種プロトコルやファイルフォーマットで 32bit な UNIX 時間が使われていることですね。

      --
      [Q][W][E][R][T][Y]
      親コメント
      • by Anonymous Coward
        ピコーン!いいこと考えた。
        ファイルのタイムスタンプを2秒単位で丸めて記録するようにすれば同じビット数で倍の期間使えるようになるぞ!
        • #ネタ元を知ってて言ってると理解していますが。

          一応解説するとFAT の修正時刻のタイムスタンプは2秒単位です。
          んでもって、いわゆる UNIX 時間ではありません。

          --
          [Q][W][E][R][T][Y]
          親コメント
        • by Anonymous Coward

          Windowsの標準機能でZip圧縮・展開して奇数秒が丸められても誰も気にしていないようだから、それほど荒唐無稽な話でもないんじゃね。
          # NTFS拡張レコードの記録に対応した圧縮ツールを使っても、Windowsの標準機能で展開すると拡張レコードは無視されるので、やっぱり奇数秒は丸められる。

        • time_t の実態が 32bit の符号付き整数であるにも関わらず
          内部では符号なし実数として扱っているのでした。

          ((~ (time_t) 0) (time_t) 0) = 1
          0x80000000 = 2038-01-19 03:14:08 UTC
          0xFFFFFFFFF = 2106-02-06 06:28:15 UTC

      • by Anonymous Coward

        バイナリファイルでバイナリ形式で、日付保存していたらバイナリファイルのフォーマットから見直しが必要で悲惨

        下手にコンパイルし直すと読み込むバイナリがずれて、プログラムが暴走しかねない

      • by Anonymous Coward

        time_t が long なシステムが多いようですが、
        これをunsigned longに直すだけで、あと70年近く先送りできると思うのですが…>32ビットunix
        たとえファイルにバイナリで埋め込まれていてもそのまま対応できるし。
        まあ一部ソースでtime_tが符号付きだと思い込んで大小比較してるようなやつは修正の必要がありますが、C言語規格でもtime_tをunsignedにしてはいけないみたいなことは書いてないので、それはそもそもそのソースが規格外ということで。

    • by Anonymous Coward
      また、64ビット化したところで根本解決ではなく2922億年問題へと問題を先送りしただけじゃないか、という話かと一瞬思った。
      • by Anonymous Coward

        その問題は弥勒菩薩様がなんとかしてくださるはず。

    • >time_t = 64bit
      「コンパイル エラー:
       修正候補: ステートメントの最後」

      by VBA

      --
      -- う~ん、バッドノウハウ?
      • by Anonymous Coward

        おもしろいつもりなのか?

  • by alternative (23238) on 2014年05月07日 8時29分 (#2595317)

    現役世代はあらかた生きているんではなかろうか。

    # うちのとーちゃんも50歳くらいから、5年以内に死ぬからと言い続けて78歳になりました

  • by Anonymous Coward on 2014年05月07日 10時17分 (#2595365)

    現在の幼稚園児・保育園児世代から「2038年は大変だ!大変だ!!」と刷り込み続ければ
    20年後には立派な意識高い人になってくれると思います!!

    • by Anonymous Coward

      私は「1999年に世界は滅亡する」と聞かされて育ってきました。
      結果、意識高くなってるかどうかはわかりません。

  • by Anonymous Coward on 2014年05月07日 12時27分 (#2595440)

    問題の先送りでしかない。

    • by Anonymous Coward

      西暦の方を0に戻すべきだよね。

      #問題の逆戻りでしかない。

      • by Anonymous Coward

        西暦の方を0に戻すべきだよね。

        それは、2038年問題を先送りするよりコストがかかりそう。

        • by Anonymous Coward on 2014年05月07日 13時51分 (#2595487)

          2000年問題華やかりし頃、外国人のエンジニアに「日本には元号があるから日付の扱いは気をつけてやってるだろ?」と聞かれて返答に困ったことを思い出しました。

          親コメント
        • by Anonymous Coward

          新暦after epochに移行しましょう

      • by Anonymous Coward

        メシア(キリスト)が生まれ直すんですよ。

    • by Anonymous Coward

      15年も前に既出のネタで今さらドヤ顔されても
      https://tools.ietf.org/html/rfc2550 [ietf.org]

  • by Anonymous Coward on 2014年05月08日 0時43分 (#2595993)

    昔、printf("Log @%d : Value = %d\n", time(NULL), foo )みたいなコードを書いて、
    Valueがずっと0で「??」と難儀した記憶があるなー。
    #VC2005だったから、GCCみたいにprintfフォーマット警告が出なかった

typodupeerror

日本発のオープンソースソフトウェアは42件 -- ある官僚

読み込み中...