アカウント名:
パスワード:
下手に元号を「??」なんかにしないでくれ。「昭和95年」とか「平成32年」を西暦に変換できるような処理系はあるけれど、元号が「??」なんかになっているデータが紛れ込んだら対処が大変じゃないか!
データベース等恒久保存データには常に西暦なりUnix時刻なりでいれて表示時に一過性で変換しろってことだよ言わせんな
64ビットで持っておけば問題無いのでは。
>生年月日をUnix Timeで保持って誰でも新人の頃に一度はする設計ミスだよね
若い人はわからないかもしれないがな、1970年1月1日よりも前に生まれた人ってのはまだたくさんいるんじゃよ…………
………
え、ちょ、マジで「1970年より前に生まれたなんて都市伝説だよね、符号なしUNIX Timeが定義できないじゃんウケルありえなーい」なんて思ってないよね?
signed 64bitで持っておけば問題無いのでは
>signed 64bitで持っておけば問題無いのでは
うんうん。「昭和100年問題」に対して、「年号の変数の幅を±64ビットでもって設計すればいいじゃんいいじゃん」ってご意見ですねw貴重なご意見ありがとうございますw
だ れ が そ の 潤 沢 な メ モ リ を 買 っ て く れ る ん じ ゃ い
Unix Timeって、負数は動作保証されてないんじゃなかったっけ?だから、time_tが32bitでも64ビットでも生年月日の表現には使えないという話だと思うけど。
>年号の変数の幅を±64ビット
誰が年号の変数の幅の話をしてるんですか?生年月日に32ビットも勿体無いって話なら最初からそう書けばよろしい。一日単位だと16ビットじゃ180年分も持たないから20ビットにでも詰めてらっしゃるんですかね。
> だ れ が そ の 潤 沢 な メ モ リ を 買 っ て く れ る ん じ ゃ い
そっちの貧乏な事情なんざ知らんがな。
せめてうるう秒ガーとかユリウス暦ガーとかいう返事を期待していたのに、まさかベテラン気取りのロートルだったとは。
保証されていないのはエラーコードとかぶる-1の値だけでしょ。仮に負の値が一切動作保証されていないシステムが過去に存在していたとして、符号付き64ビットに改修するの前提な話なのにわざわざそのバグを引き継ぐんですか。
おじいちゃん、一億人分の生年月日を32ビットから64ビットに増やしたとしてもデータベース全体で3ギガバイトしか増えないの。
Unix Time以前生まれのおじいちゃんの頃は「潤沢なメモリ」に見えたかもしれないけど、今時そんなのおじいちゃんの大好きなエロ動画、昔はブルーフィルムって言ったんだっけ?一本分にもならないかもしれないの。時代は変わったのよ。
規格が負の時刻の扱いを保証していない
[要出典]
値が-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)
>signed 64bitで持っておけば問題無いのでは
うんうん。「昭和100年問題」に対して、「年号の変数の幅を±64ビットでもって設計すればいいじゃんいいじゃん」ってご意見ですねw
貴重なご意見ありがとうございますw
だ れ が そ の 潤 沢 な メ モ リ を 買 っ て く れ る ん じ ゃ い
Re: (スコア:0)
Unix Timeって、負数は動作保証されてないんじゃなかったっけ?
だから、time_tが32bitでも64ビットでも生年月日の表現には使えないという話だと思うけど。
Re: (スコア:0)
>年号の変数の幅を±64ビット
誰が年号の変数の幅の話をしてるんですか?
生年月日に32ビットも勿体無いって話なら最初からそう書けばよろしい。
一日単位だと16ビットじゃ180年分も持たないから20ビットにでも詰めてらっしゃるんですかね。
> だ れ が そ の 潤 沢 な メ モ リ を 買 っ て く れ る ん じ ゃ い
そっちの貧乏な事情なんざ知らんがな。
せめてうるう秒ガーとかユリウス暦ガーとかいう返事を期待していたのに、
まさかベテラン気取りのロートルだったとは。
Re: (スコア:0)
保証されていないのはエラーコードとかぶる-1の値だけでしょ。
仮に負の値が一切動作保証されていないシステムが過去に存在していたとして、
符号付き64ビットに改修するの前提な話なのにわざわざそのバグを引き継ぐんですか。
Re: (スコア:0)
規格が負の時刻の扱いを保証していないのだから
仮に負の値が一切動作保証されているシステムが現在に存在していたとしても
その機能を使用しているコードに移植性はない
Re: (スコア:0)
おじいちゃん、一億人分の生年月日を32ビットから64ビットに増やしたとしてもデータベース全体で3ギガバイトしか増えないの。
Unix Time以前生まれのおじいちゃんの頃は「潤沢なメモリ」に見えたかもしれないけど、
今時そんなのおじいちゃんの大好きなエロ動画、昔はブルーフィルムって言ったんだっけ?
一本分にもならないかもしれないの。
時代は変わったのよ。
Re: (スコア:0)
[要出典]
値が-1の時は保証されていない。 [srad.jp]それ以外の負の時刻の扱いが保証されていないソースは?
Re: (スコア:0)