(13)ギャラリOgnacの試行部屋コミュニティ日付型に思う文化が変わればマジックナンバーの意識も変わる。77,88は特別な意味を持ちます。日常会話で「77がこうなって、88が有効で」等と交わされます。この世界では77/88はマジックナンバーではないのですね。前振りにもなってなくて話題が変わるのですが、前回のエントリーのコメントに興味深い文言がありました。日付の値に未定という違う次元の状態を含ませようという意味ですね。私はオープン系ての設計ではは好ましくないと考えてます。未定/決定項目を別途設定したいところです。NULLとして保持(未定か未登録かの識別できないので問題ですが)します。厳密な型規定と項目の意味付けを単一するのがベターだと考えるのです。/IronRubyなどDLR系が出てくるので考えが変わりそうな気もしますが.....)コボルなど汎用機のシステムでは日付を違った使い方でしているシステムが結構存在したりします。売上データなど当日発生の書類を事務決済処理に数日間要して後日電算機に入力するときは2~5日後になるのは不可避です。ここでは、売上げ日を2007年8月31日(金)とします31日に締めて書類を纏めて決済を仰ぐのは早くて9月3日になり電算室に回ってくる間は9月4日以降になる可能性は高いですね。8月35日と登録します。して同月データとして処理します。Date型では扱えない日付処理を強いられたりします。コボル文化が存在するのは過去の開発資産の多さだけでなく、設計思想の差もあって単純には移行できないんだなと考えたりします。30時間制にして欲しいと聞いたことがあります。翌朝までは前日のデータとして扱いたいそうです。オープン系の開発でも拡張日付型が必要になってくるかも知れませんね。月末を意味する日に99日というのはよくありますよね。2007/02/99ただ月末を31日にするのには困りました。2/11:13:00の稼働時間27時間ってのも苦手まだまだですな。通り*エントリで取り上げてもらえてうれしい~。悪い例なのでハズカシイw2999年というか、普通ではない未来の日付を入力したかったようでした。2007/02/31昨日かおとといのニュースで言ってた、宙に浮いた年金問題の原因(の可能性の一つ)を思い出しましたwシステム入力時に存在しない生年月日を入力したために、その後の処理でおかしくなった可能性もある、みたいな。Ognac>月末を意味する日に99日というのはよくありますよね。>ただ月末を31日にするのには困りました。業務上必要なクラスですね。>エントリで取り上げてもらえてうれしい~。悪い例なのでハズカシイw無許可で勝手に取り上げてごめんなさい。(^_^;)後一つ、取り上げたいキーワードがあります。月末の意味を持たせるというのは業務仕様であって、型の預かり知らぬことですね。仕様が伝わっているうちはシステムは健全ですが、DB設計のみ引き継がれたりしたらアブノーマルデータとみなされ、データ破棄てなことになりかねません。消えた年金データの一因かもと勘ぐってみたり。n時間制これに含まれるかもしれないけど、夜勤の午前6時とかは前日扱いにするってのもありました。後一つ、取り上げたいキーワードがあります。消えた年金データの一因かもと勘ぐってみたりニュースでは専門家みたいな人がそんなこと言ってました。trapemiya放送を扱う場合はだいたい31時間制か32時間制です。時間取り契約なんかも未定であることが多いため、これらは9999年99月99日になります。これはCOBOLの時代から今のVB6製のEDPSまでおんなじです。これらをどやって扱うかといえば、もちろん文字列型です。COBOLの時代には日付計算なんて便利なものがないから、閏年なんかも自前で計算したもんです。あと経理なんかは決算処理の関係で1年が13ヶ月だったりすることもあります。Ognac日付型では役不足な業種は結構あるのですね。拡張日付型を標準搭載にしたいですね。あきひろ製造業の生産に近いところも30時間制みたいなのが多いですね。勤務体系が2勤体制で夜勤は0時はさみますが、「○日の2勤」で扱いますので。文字列型になりますね。日付型では役不足だうと。いう俺ンとこも、最近26時とかを扱う必要が出てきて四苦八苦してます。