「2038年問題、早くも顕在化」記事へのコメント

time_tをsigned __int64に変更するとしたら

[deleted user (18918)]

世界全体で合計どのくらいコストがかかるのかな。

＃ILP64な環境だとtime_tはどう定義されてるか興味津々

Re:time_tをsigned __int64に変更するとしたら

[Anonymous Coward]

> time_tをsigned __int64に変更するとしたら

time_tそのものは32bitだと決まってるわけではないので
変更の必要性はありません。

ちゃんと作ってればソースへの変更は不要。
もっとちゃんと作ってればリコンパイルも不要。
数十年や数百年先、
さらには同じような扱いで数十年前や数百年前の時刻を
秒単位で管理するソフト作る場合は
始めからtime_tを利用せず代替ライブラリーを自分で用意するし。

結局のところ表現したい時刻の範囲と
それぞれの型によって表現可能な時刻の範囲の問題に関して
ちゃんと考えたことがあるのか、それともないのか
という点につきますよ

どういう理由で

Re:time_tをsigned __int64に変更するとしたら

[Anonymous Coward]

結局のところ表現したい時刻の範囲と それぞれの型によって表現可能な時刻の範囲の問題に関して ちゃんと考えたことがあるのか、それともないのか という点につきますよ

ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね？
まだ、そういう仕様のところって多いんじゃないかなぁ。

と、それはそれとして…

どういう理由でそんな仕様にしたのか尋ねても「覚えてない」

行員矢の如し

[hix (3507)]

2038/01/19 03:14:07 UTCを過ぎたら、それ以前のことは全て忘れてしまえばよいのです。

以降、time_tの説明には

time_t型に格納される数値は 2106/02/05 21:28:16 UTCまでの秒数を負の値で表したものです。
time_t型が正常に動作する最も古い時刻は2038/01/19 03:14:08 UTC です。 それより前の時刻をコンピュータで取り扱うのは原因不明の事故や故障に繋がりますのでおやめください。非常に危険です。多分死人が出ます。
2038/01/19 03:14:08 UTC より前からの債権について金利計算を行うには、正常に動作する時刻からの金利とすることが最善の解決策です。
なお、2106/02/05 21:28:16 UTCを過ぎた時刻は、time_t型に正の秒数で格納されます。当面の時刻を正常に表す事ができます。

とでも書いておけば宜しい。