アカウント名:
パスワード:
OSの内部的な時刻の表現は64ビット化が進んでいて西暦3000億年まで大丈夫になりつつあるようです。スクリプト系言語は32ビットとして扱ってなければそのままでも大丈夫なような。データベースのカラムが32ビットだったらダメですけど。time型カラムとかdatetime型カラムは対応が進んでそう。
それにしても動作確認が大変そうですね・・・
実際のところ, 抽象的な時刻型で記述してあるプログラムについては, それほど大きな問題にはならないのではないかと思います.
問題なのは時刻型を32bit符号付き整数という前提でcastして取り扱っていたり, あるいはcastさえせずにwarning無視で使っていたりするケースじゃないでしょうか. そういう類のプログラムだと, 事は時刻型だけにとどまらず他の各種のデータについても同様の潜在バグを抱えていることがままあります. そうすると, 今日的なチェックの厳しいコンパイラだとコンパイルを通らない. コンパイルを通っても, そもそもバグを抱えていたのがたまたま動いていただけなので, まともに動きようがない. 結果としてプログラムの直しようもなく, 旧来のバイナリをそのまま使わざるをえない. ってところかと.
Cなんかが業務システムで使われるようになって, そろそろ30年ってところですから, ソースが紛失したなんてケースも少なからずありそうな.
実はVARCHAR2だから問題ない所が多かったり
やめて。
この間も、何故かほぼ全てのフィールドがTEXT型のPostgreSQLデータベースで悩んだよ…。
Y2Kは、CHARで年を下二桁にしてたから起きたわけですけどね。まあ年を4桁取って安心してる面々も、まさか同じプログラムが西暦1万年に問題を起こすとは夢にも思わなかったと言う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
意外と大丈夫? (スコア:0)
OSの内部的な時刻の表現は64ビット化が進んでいて西暦3000億年まで大丈夫になりつつあるようです。
スクリプト系言語は32ビットとして扱ってなければそのままでも大丈夫なような。
データベースのカラムが32ビットだったらダメですけど。time型カラムとかdatetime型カラムは対応が進んでそう。
それにしても動作確認が大変そうですね・・・
Re:意外と大丈夫? (スコア:2)
実際のところ, 抽象的な時刻型で記述してあるプログラムについては, それほど大きな問題にはならないのではないかと思います.
問題なのは時刻型を32bit符号付き整数という前提でcastして取り扱っていたり, あるいはcastさえせずにwarning無視で使っていたりするケースじゃないでしょうか. そういう類のプログラムだと, 事は時刻型だけにとどまらず他の各種のデータについても同様の潜在バグを抱えていることがままあります. そうすると, 今日的なチェックの厳しいコンパイラだとコンパイルを通らない. コンパイルを通っても, そもそもバグを抱えていたのがたまたま動いていただけなので, まともに動きようがない. 結果としてプログラムの直しようもなく, 旧来のバイナリをそのまま使わざるをえない. ってところかと.
Cなんかが業務システムで使われるようになって, そろそろ30年ってところですから, ソースが紛失したなんてケースも少なからずありそうな.
Re: (スコア:0)
実はVARCHAR2だから問題ない所が多かったり
Re: (スコア:0)
やめて。
この間も、何故かほぼ全てのフィールドがTEXT型のPostgreSQLデータベースで悩んだよ…。
Re: (スコア:0)
Y2Kは、CHARで年を下二桁にしてたから起きたわけですけどね。
まあ年を4桁取って安心してる面々も、まさか同じプログラムが西暦1万年に問題を起こすとは夢にも思わなかったと言う。