パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

OpenBSD 5.5、2038年問題に対応」記事へのコメント

  • 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 on 2014年05月07日 21時47分 (#2595892)
        ピコーン!いいこと考えた。
        ファイルのタイムスタンプを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

物事のやり方は一つではない -- Perlな人

処理中...