アカウント名:
パスワード:
どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけどDBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。検索やソートの速度もわりと問題無かったし。でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
DBのDATEとかTIMESTAMPにするとな、時刻までもってるからって日付の処理を日時で処理する派遣PGがいるんだよ。若しくはSYSDATEとかで現在時刻を突っ込むDB管理者がな、いるんだよ。
もっとも、文字列や数値にしたところで、こんな奴らは何かとやらかしてくれるのでフールプルーフにはならんのだけど・・・そういや月の加減処理が正しく出来ないなんて低レベルなことしてくれた奴も前世紀にみたっけ。
特別な理由がなければ普通は素直に日付型使っとけと思いますけどね。
日付は日付・時間は時間。それをゴッチャにされたものがあんなに扱い辛くなるとは思ってもみなかった。そういうのに限って、デザインした奴は直ぐに消えて他人任せになるのだもんな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
本当に西暦で持つの? (スコア:2, すばらしい洞察)
どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけど
DBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。
これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。
検索やソートの速度もわりと問題無かったし。
でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも
時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
Re:本当に西暦で持つの? (スコア:0)
DBのDATEとかTIMESTAMPにするとな、時刻までもってるからって日付の処理を日時で処理する派遣PGがいるんだよ。
若しくはSYSDATEとかで現在時刻を突っ込むDB管理者がな、いるんだよ。
もっとも、文字列や数値にしたところで、こんな奴らは何かとやらかしてくれるのでフールプルーフにはならんのだけど・・・
そういや月の加減処理が正しく出来ないなんて低レベルなことしてくれた奴も前世紀にみたっけ。
特別な理由がなければ普通は素直に日付型使っとけと思いますけどね。
Re: (スコア:0)
日付は日付・時間は時間。
それをゴッチャにされたものがあんなに扱い辛くなるとは思ってもみなかった。
そういうのに限って、デザインした奴は直ぐに消えて他人任せになるのだもんな。