Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

日付型に思う

文化が変わればマジックナンバーの意識も変わる。
 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時間制にして欲しいと聞いたことがあります。翌朝までは前日のデータとして扱いたいそうです。
オープン系の開発でも拡張日付型が必要になってくるかも知れませんね。(個別で作れば済む問題ですが)

投稿日時 : 2007年6月1日 10:52

Feedback

# re: 日付型に思う 2007/06/01 11:04 中博俊

月末を意味する日に99日というのはよくありますよね。
2007/02/99
ただ月末を31日にするのには困りました。
2007/02/31
うーん
ちなみに2007/02と月末チェックがいいと思いますが、今のDateTimeなどは年だけ、月だけを表しにくいし、2/10 10:00 ~ 2/11:13:00の稼働時間27時間ってのも苦手

まだまだですな。

# re: 日付型に思う 2007/06/01 12:59 通り*

エントリで取り上げてもらえてうれしい~。けど悪い例なのでハズカシイw
2999年というか、普通ではない未来の日付を入力したかったようでした。
日付値チェック無しのシステムでそのような運用をされていて、私のチェック入りの画面で不都合が..;

> 2007/02/31
昨日かおとといのニュースで言ってた、宙に浮いた年金問題の原因(の可能性の一つ)を思い出しましたw
システム入力時に存在しない生年月日を入力したために、その後の処理でおかしくなった可能性もある、みたいな。
そんなことで大切な(ry

やっぱりシステム固有日付型の定義でしょうかねぇ?
そしてデータベース格納時は文字型でw(これ、笑えない冗談かも)

# re: 日付型に思う 2007/06/01 17:06 Ognac

>月末を意味する日に99日というのはよくありますよね。
うんうんありますね。
>ただ月末を31日にするのには困りました。
>まだまだですな。
そうですね、 日付値 + 月末の意味 + n時間制 + NULL が可能なクラスは 業務上必要なクラスですね。


>エントリで取り上げてもらえてうれしい~。けど悪い例なのでハズカシイw
無許可で勝手に取り上げてごめんなさい。(^_^;)
後一つ、取り上げたいキーワードがあります。よろしいでしょうか? (否定を想定してない自分がいます)

>(これ、笑えない冗談かも)
・"2999/12/31"に未定の意味を持たせる
・ /99 or /31 に月末の意味を持たせる
というのは業務仕様であって、型の預かり知らぬことですね。仕様が伝わっているうちはシステムは健全ですが、DB設計のみ引き継がれたりしたらアブノーマルデータとみなされ、データ破棄てなことになりかねません。
消えた年金データの一因かもと勘ぐってみたり。

# re: 日付型に思う 2007/06/01 17:33 通り*

> n時間制
これに含まれるかもしれないけど、夜勤の午前6時とかは前日扱いにするってのもありました。

> 後一つ、取り上げたいキーワードがあります。よろしいでしょうか?
え、私の? ダメですよ(って言うわけないですよw)
#何だろ...不安です
他の人のでもきっといいと思いますよ(勝手なw)

> 消えた年金データの一因かもと勘ぐってみたり
ニュースでは専門家みたいな人がそんなこと言ってました。
(生年月日が異なれば、たとえ正しい日付でもダメだったのかもしれませんが...)

# re: 日付型に思う 2007/06/02 20:41 trapemiya

放送を扱う場合はだいたい31時間制か32時間制です。それまでに日替わり処理が入ります。放送番組終了未定や時間取り契約なんかも未定であることが多いため、これらは9999年99月99日になります。これはCOBOLの時代から今のVB6製のEDPSまでおんなじです。
これらをどやって扱うかといえば、もちろん文字列型です。
COBOLの時代には日付計算なんて便利なものがないから、閏年なんかも自前で計算したもんです。

あと経理なんかは決算処理の関係で1年が13ヶ月だったりすることもあります。

# re: 日付型に思う 2007/06/03 0:34 Ognac

日付型では役不足な業種は結構あるのですね。
拡張日付型を標準搭載にしたいですね。

# re: 日付型に思う 2007/06/04 8:58 あきひろ

製造業の生産に近いところも30時間制みたいなのが多いですね。勤務体系が2勤体制で夜勤は0時はさみますが、「○日の2勤」で扱いますので。当然文字列型になりますね。

# re: 日付型に思う 2007/06/04 10:23 シャノン

> 日付型では役不足
だうと。

かくいう俺ンとこも、最近26時とかを扱う必要が出てきて四苦八苦してます。

# re: 日付型に思う 2007/06/05 0:43 Ognac

日付型と時刻型を独立させるべし...と言ったら通るかな?

タイトル  
名前  
Url
コメント