文化が変わればマジックナンバーの意識も変わる。
COBOLのデータ定義句/Sectionでは 77,88は特別な意味を持ちます。
日常会話で「77がこうなって、88が有効で」等と交わされます。この世界では77/88はマジックナンバーではないのですね。
前振りにもなってなくて話題が変わるのですが、前回のエントリーのコメントに興味深い文言がありました。
>日付値のチェックを入れたら、「未定の場合は 2999年で入力したいのに」
日付の値に未定という違う次元の状態を含ませようという意味ですね。私はオープン系ての設計ではは好ましくないと考えてます。未定/決定項目を別途設定したいところです。もしくはNULLとして保持(未定か未登録かの識別できないので問題ですが)します。
厳密な型規定と項目の意味付けを単一するのがベターだと考えるのです。
(といいながら、今後IronPython /IronRubyなどDLR系が出てくるので考えが変わりそうな気もしますが.....)
コボルなど汎用機のシステムでは日付を違った使い方でしているシステムが結構存在したりします。
売上データなど当日発生の書類を事務決済処理に数日間要して後日電算機に入力するときは2～5日後になるのは不可避です。ここでは、売上げ日を2007年8月31日(金)とします31日に締めて書類を纏めて決済を仰ぐのは早くて9月3日になり電算室に回ってくる間は9月4日以降になる可能性は高いですね。
(年度締めが 8月31日だったら尚更ですが)月をまたいで前月データを処理するのは複雑さを伴うので、売上日は 8月31日 、売上確定日は 8月34日 データ入力日は 8月35日と登録します。こうして同月データとして処理します。
Date型では扱えない日付処理を強いられたりします。
コボル文化が存在するのは過去の開発資産の多さだけでなく、設計思想の差もあって単純には移行できないんだなと考えたりします。
昨今では、24時間営業や深夜営業の店のデータ処理で、時刻を24:00制でなく 30時間制にして欲しいと聞いたことがあります。翌朝までは前日のデータとして扱いたいそうです。
オープン系の開発でも拡張日付型が必要になってくるかも知れませんね。(個別で作れば済む問題ですが)