アカウント名:
パスワード:
こういうのを 2038 年問題の 1 つと言ってしまって良いのでしょうか? これは time_t 型の仕様限界による問題ではなくて、単に開発者が time_t 型の仕様を理解していなかっただけの話ですよね?
単に開発者が time_t 型の仕様を理解していなかった
好意的に推測しすぎ。time_t なんて使ってやしないでしょ。おそらく。 int だと思っているから「2倍する」なんて操作をしているの。なんで2倍するのか知らないけど、時刻でなく何か別の用途に使う数値の元ネタにしているのかもね。それでも正の値でないとまずいとかさ。
時刻を内部でどう扱っていても固定サイズで扱っていればいつかはあふれる。それが現実に運用期間中に来ることを考慮しなくて(想像すらできなくて)問題を発生させれば、それはバグ。 西暦年を2桁で表せば2000年問題だし、 エポックからの秒数を9桁の文字列で表せば10億秒問題だし、 1970年1月1日のエポックからの秒数を32ビット符号つき整数で取り扱えば2038年問題。 根は同じだけど、皆して同じバグを作っているからそれぞれ発症時期の名前がついている。 だから、今回のは2004年1月問題かもしれないけど、2038年問題では断じてない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
2038 年問題? (スコア:2, すばらしい洞察)
こういうのを 2038 年問題の 1 つと言ってしまって良いのでしょうか? これは time_t 型の仕様限界による問題ではなくて、単に開発者が time_t 型の仕様を理解していなかっただけの話ですよね?
むらちより/あい/をこめて。
Re:2038 年問題? (スコア:1, 興味深い)
好意的に推測しすぎ。time_t なんて使ってやしないでしょ。おそらく。
int だと思っているから「2倍する」なんて操作をしているの。なんで2倍するのか知らないけど、時刻でなく何か別の用途に使う数値の元ネタにしているのかもね。それでも正の値でないとまずいとかさ。
時刻を内部でどう扱っていても固定サイズで扱っていればいつかはあふれる。それが現実に運用期間中に来ることを考慮しなくて(想像すらできなくて)問題を発生させれば、それはバグ。
西暦年を2桁で表せば2000年問題だし、 エポックからの秒数を9桁の文字列で表せば10億秒問題だし、 1970年1月1日のエポックからの秒数を32ビット符号つき整数で取り扱えば2038年問題。
根は同じだけど、皆して同じバグを作っているからそれぞれ発症時期の名前がついている。
だから、今回のは2004年1月問題かもしれないけど、2038年問題では断じてない。