アカウント名:
パスワード:
どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけどDBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。検索やソートの速度もわりと問題無かったし。でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
決定権持ってる人がデータ形式なんて理解できるわけないじゃない手書き紙ベースで出来るのになんでできないんだとしか思ってないよ下は上に具申する権限すらないので朝令暮改もありうる
キャリア官僚系は課長補佐クラス(30代くらい)が事実上の決定権を持っていて課長より上は決裁権はあるけれどほとんどのことについては事実上ハンコ押すマシンだ、と聞いたことがあるけれど
決定権を持つのは顧客です!
#なお客先担当者に決定権はない
決定権が無ければ良いのだが、顧客の要望の認可権を持って居て実質仕様の決定権を持って居るのと同じ事を自分の責任無しでやってしまうのががが…
そんなソースだったら日付型を採用しててもdate型とtimestamp型の比較でバグを出してるでしょうよ。あとタイムゾーンが人類には難しすぎる。サマータイムとか絶対無理。
手書きの内容をそのまま保存()が原因→文字列保存。だから日付として解釈不可の値が普通に入ってる。「弐拾壱日」みたいなのはマシな方。さらに打ち間違い言うか見た目だけで「ニ」(半角カナの「に」)を2として入れてたり。
だが処理時には正しい日付としてちゃんと処理しろ()なんだよね。
通達
開示請求で公開しない文書は13月以降の月日とする
DBのDATEとかTIMESTAMPにするとな、時刻までもってるからって日付の処理を日時で処理する派遣PGがいるんだよ。若しくはSYSDATEとかで現在時刻を突っ込むDB管理者がな、いるんだよ。
もっとも、文字列や数値にしたところで、こんな奴らは何かとやらかしてくれるのでフールプルーフにはならんのだけど・・・そういや月の加減処理が正しく出来ないなんて低レベルなことしてくれた奴も前世紀にみたっけ。
特別な理由がなければ普通は素直に日付型使っとけと思いますけどね。
日付は日付・時間は時間。それをゴッチャにされたものがあんなに扱い辛くなるとは思ってもみなかった。そういうのに限って、デザインした奴は直ぐに消えて他人任せになるのだもんな。
こういう事情って海外ではどーなんだろMMDDYYYYな地域とか文字列で持っちゃうとソートが死にそうだけど
内部はなんだっていいんだよ。YYYYMMDDでもUNIX秒でも。だいたい内部で元号なんて使ってるところなんてないでしょ。
システムの内部表現に関する傾向をご存知とは、すごいスーパーハカーなのですね昭和100年問題なんて、ただの陰謀なのですね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
本当に西暦で持つの? (スコア:2, すばらしい洞察)
どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけど
DBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。
これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。
検索やソートの速度もわりと問題無かったし。
でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも
時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
Re: (スコア:0)
決定権持ってる人がデータ形式なんて理解できるわけないじゃない
手書き紙ベースで出来るのになんでできないんだとしか思ってないよ
下は上に具申する権限すらないので朝令暮改もありうる
Re: (スコア:0)
キャリア官僚系は課長補佐クラス(30代くらい)が事実上の決定権を持っていて
課長より上は決裁権はあるけれどほとんどのことについては
事実上ハンコ押すマシンだ、と聞いたことがあるけれど
Re:本当に西暦で持つの? (スコア:1)
元請SEより上はエクセルに線を引くマシーンじゃないの
# なお両者とも決定権はない
Re: (スコア:0)
決定権を持つのは顧客です!
#なお客先担当者に決定権はない
Re: (スコア:0)
決定権が無ければ良いのだが、顧客の要望の認可権を持って居て実質仕様の決定権を持って居るのと同じ事を自分の責任無しでやってしまうのががが…
Re: (スコア:0)
そんなソースだったら日付型を採用しててもdate型とtimestamp型の比較でバグを出してるでしょうよ。あとタイムゾーンが人類には難しすぎる。サマータイムとか絶対無理。
Re: (スコア:0)
手書きの内容をそのまま保存()が原因
→文字列保存。
だから日付として解釈不可の値が普通に入ってる。「弐拾壱日」みたいなのはマシな方。
さらに打ち間違い言うか見た目だけで「ニ」
(半角カナの「に」)を2として入れてたり。
だが処理時には正しい日付としてちゃんと処理しろ()なんだよね。
Re: (スコア:0)
通達
開示請求で公開しない文書は13月以降の月日とする
Re: (スコア:0)
DBのDATEとかTIMESTAMPにするとな、時刻までもってるからって日付の処理を日時で処理する派遣PGがいるんだよ。
若しくはSYSDATEとかで現在時刻を突っ込むDB管理者がな、いるんだよ。
もっとも、文字列や数値にしたところで、こんな奴らは何かとやらかしてくれるのでフールプルーフにはならんのだけど・・・
そういや月の加減処理が正しく出来ないなんて低レベルなことしてくれた奴も前世紀にみたっけ。
特別な理由がなければ普通は素直に日付型使っとけと思いますけどね。
Re: (スコア:0)
日付は日付・時間は時間。
それをゴッチャにされたものがあんなに扱い辛くなるとは思ってもみなかった。
そういうのに限って、デザインした奴は直ぐに消えて他人任せになるのだもんな。
Re: (スコア:0)
こういう事情って海外ではどーなんだろ
MMDDYYYYな地域とか文字列で持っちゃうとソートが死にそうだけど
Re: (スコア:0)
Re: (スコア:0)
内部はなんだっていいんだよ。YYYYMMDDでもUNIX秒でも。
だいたい内部で元号なんて使ってるところなんてないでしょ。
Re: (スコア:0)
システムの内部表現に関する傾向をご存知とは、すごいスーパーハカーなのですね
昭和100年問題なんて、ただの陰謀なのですね