アカウント名:
パスワード:
結局のところ表現したい時刻の範囲と それぞれの型によって表現可能な時刻の範囲の問題に関して ちゃんと考えたことがあるのか、それともないのか という点につきますよ
と、それはそれとして…
どういう理由でそんな仕様にしたのか尋ねても「覚えてない」 「何も考えてなかった」とか言い出す連中は 設計の段階で何も検証してません。
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型に正の秒数で格納されます。当面の時刻を正常に表す事ができます。
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を 行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。
「多い」と結論付ける資料も計算式も不明ですが。
結局はソースレビューするしか品質を維持できないと思ってます。
実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそ
ソースの品質を向上させたり保証する能力と設計に関する能力を一緒にしちゃダメってことです。
まぁ、普通そういう人が多いことは知っていますが(そうじゃないと困る人が多いというか)、今の現状でいうと、ソースも読めない人が上位設計をやっていることが結構あるんですね。で、本人は上級なことをやっている気になっているんですが、元々ソースも読めない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
time_tをsigned __int64に変更するとしたら (スコア:1)
#ILP64な環境だとtime_tはどう定義されてるか興味津々
Re:time_tをsigned __int64に変更するとしたら (スコア:2, すばらしい洞察)
time_tそのものは32bitだと決まってるわけではないので
変更の必要性はありません。
ちゃんと作ってればソースへの変更は不要。
もっとちゃんと作ってればリコンパイルも不要。
数十年や数百年先、
さらには同じような扱いで数十年前や数百年前の時刻を
秒単位で管理するソフト作る場合は
始めからtime_tを利用せず代替ライブラリーを自分で用意するし。
結局のところ表現したい時刻の範囲と
それぞれの型によって表現可能な時刻の範囲の問題に関して
ちゃんと考えたことがあるのか、それともないのか
という点につきますよ
どういう理由で
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
まだ、そういう仕様のところって多いんじゃないかなぁ。
と、それはそれとして…
行員矢の如し (スコア:1)
以降、time_tの説明には とでも書いておけば宜しい。
Re:time_tをsigned __int64に変更するとしたら (スコア:1)
これはちょっと違うのでは?
仕様として決まっている事は全部テストでチェックすればいいだけだし。
仕様定義やテストの漏れこそが致命的であって、その部分のチェック
の方が重要だと思う。
ソースレベルのチェックなんてコーディング規約ぐらいのもんだろうから
その辺はプログラマレベルで解決して欲しい。
間違っても上位設計者にそんなことやらせちゃ駄目です。
建築士が柱を運ぶようなもんで、職掌(や単価)が違うんだから。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
(量産型の家と特注の家。どちらに住みたいかは人それぞれですが。)
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
小規模プロジェクトの場合、設計担当者が製造の現場監督を兼任することもある、
という実例ですね。
設計担当者には製造の現場監督とし
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
「多い」と結論付ける資料も計算式も不明ですが。
実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそ
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
まぁ、普通そういう人が多いことは知っていますが(そうじゃないと困る人が多いというか)、今の現状でいうと、ソースも読めない人が上位設計をやっていることが結構あるんですね。で、本人は上級なことをやっている気になっているんですが、元々ソースも読めない
Re:time_tをsigned __int64に変更するとしたら (スコア:0)