アカウント名:
パスワード:
どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけどDBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。検索やソートの速度もわりと問題無かったし。でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
そんなソースだったら日付型を採用しててもdate型とtimestamp型の比較でバグを出してるでしょうよ。あとタイムゾーンが人類には難しすぎる。サマータイムとか絶対無理。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
本当に西暦で持つの? (スコア:2, すばらしい洞察)
どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけど
DBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。
これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。
検索やソートの速度もわりと問題無かったし。
でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも
時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
Re:本当に西暦で持つの? (スコア:0)
そんなソースだったら日付型を採用しててもdate型とtimestamp型の比較でバグを出してるでしょうよ。あとタイムゾーンが人類には難しすぎる。サマータイムとか絶対無理。