アカウント名:
パスワード:
下手に元号を「??」なんかにしないでくれ。「昭和95年」とか「平成32年」を西暦に変換できるような処理系はあるけれど、元号が「??」なんかになっているデータが紛れ込んだら対処が大変じゃないか!
データベース等恒久保存データには常に西暦なりUnix時刻なりでいれて表示時に一過性で変換しろってことだよ言わせんな
64ビットで持っておけば問題無いのでは。
>生年月日をUnix Timeで保持って誰でも新人の頃に一度はする設計ミスだよね
若い人はわからないかもしれないがな、1970年1月1日よりも前に生まれた人ってのはまだたくさんいるんじゃよ…………
………
え、ちょ、マジで「1970年より前に生まれたなんて都市伝説だよね、符号なしUNIX Timeが定義できないじゃんウケルありえなーい」なんて思ってないよね?
signed 64bitで持っておけば問題無いのでは
Unix Timeって、負数は動作保証されてないんじゃなかったっけ?だから、time_tが32bitでも64ビットでも生年月日の表現には使えないという話だと思うけど。
保証されていないのはエラーコードとかぶる-1の値だけでしょ。仮に負の値が一切動作保証されていないシステムが過去に存在していたとして、符号付き64ビットに改修するの前提な話なのにわざわざそのバグを引き継ぐんですか。
規格が負の時刻の扱いを保証していない
[要出典]
値が-1の時は保証されていない。 [srad.jp]それ以外の負の時刻の扱いが保証されていないソースは?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
被害甚大 (スコア:-1)
下手に元号を「??」なんかにしないでくれ。「昭和95年」とか「平成32年」を西暦に変換できるような処理系はあるけれど、元号が「??」なんかになっているデータが紛れ込んだら対処が大変じゃないか!
Re: (スコア:0)
データベース等恒久保存データには常に西暦なりUnix時刻なりでいれて表示時に一過性で変換しろってことだよ言わせんな
Re: (スコア:0)
Re: (スコア:0)
64ビットで持っておけば問題無いのでは。
Re: (スコア:0)
>生年月日をUnix Timeで保持って誰でも新人の頃に一度はする設計ミスだよね
64ビットで持っておけば問題無いのでは。
若い人はわからないかもしれないがな、1970年1月1日よりも前に生まれた人ってのはまだたくさんいるんじゃよ…………
………
………
え、ちょ、マジで「1970年より前に生まれたなんて都市伝説だよね、符号なしUNIX Timeが定義できないじゃんウケルありえなーい」なんて思ってないよね?
Re: (スコア:0)
signed 64bitで持っておけば問題無いのでは
Re: (スコア:0)
Unix Timeって、負数は動作保証されてないんじゃなかったっけ?
だから、time_tが32bitでも64ビットでも生年月日の表現には使えないという話だと思うけど。
Re:被害甚大 (スコア:0)
保証されていないのはエラーコードとかぶる-1の値だけでしょ。
仮に負の値が一切動作保証されていないシステムが過去に存在していたとして、
符号付き64ビットに改修するの前提な話なのにわざわざそのバグを引き継ぐんですか。
Re: (スコア:0)
規格が負の時刻の扱いを保証していないのだから
仮に負の値が一切動作保証されているシステムが現在に存在していたとしても
その機能を使用しているコードに移植性はない
Re: (スコア:0)
[要出典]
値が-1の時は保証されていない。 [srad.jp]それ以外の負の時刻の扱いが保証されていないソースは?
Re: (スコア:0)