アカウント名:
パスワード:
どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけどDBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。検索やソートの速度もわりと問題無かったし。でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
手書きの内容をそのまま保存()が原因→文字列保存。だから日付として解釈不可の値が普通に入ってる。「弐拾壱日」みたいなのはマシな方。さらに打ち間違い言うか見た目だけで「ニ」(半角カナの「に」)を2として入れてたり。
だが処理時には正しい日付としてちゃんと処理しろ()なんだよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
本当に西暦で持つの? (スコア:2, すばらしい洞察)
どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけど
DBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。
これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。
検索やソートの速度もわりと問題無かったし。
でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも
時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
Re:本当に西暦で持つの? (スコア:0)
手書きの内容をそのまま保存()が原因
→文字列保存。
だから日付として解釈不可の値が普通に入ってる。「弐拾壱日」みたいなのはマシな方。
さらに打ち間違い言うか見た目だけで「ニ」
(半角カナの「に」)を2として入れてたり。
だが処理時には正しい日付としてちゃんと処理しろ()なんだよね。