単なる数値を日付として認識させるには

過去の桐井戸端ＢＢＳ　（桐ver.７）

3495	単なる数値を日付として認識させるには	ちんぷんかんぷん	1999/11/25-22:54
ｖ７を使用しています。テキスト形式（固定長）でくる注文データを表に読み込み日程管理をしようと考えていますが日付の部分が単なる6桁の数値（1999年11月25日であれば991125）になっています。これをコンピューターに日付として認識させるにはどうしたらいいでしょうか。何千という大量のデータなのでいちいち　/　や年、月、日を手入力するわけもいきません。初歩的な質問かもしれませんがどなたか教えてください。
3496	Re:単なる数値を日付として認識させるには	Ogo	1999/11/25-23:33
記事番号3495へのコメント >テキスト形式（固定長）でくる注文データを表に読み込み日程管理をしようと >考えていますが日付の部分が単なる6桁の数値（1999年11月25日であれば991125） >になっています。これをコンピューターに日付として認識させるにはどうしたらい >いでしょうか。当掲示板の過去ログの http://www.fuku3.com/~habata/kbbs/kakov8/02274.htm を参照して下さい（ V7 も V8 も同じことでしょう）。これと同じような（方向性は全く逆の）内容のやり取りがあります。今回の場合は、その中の #2314 の発言が最も役に立つかな。テキスト形式（固定長）をそのまま読み込むためだけの項目を作成しておいてそれを「別項目の日付型項目」に有効なデータとして入力するようにします。この時、「別項目の日付型項目」を項目計算式で定義するか、または自由入力項目にしておいて「置換」を使ってコンバートするかは、仕事の種類によって適切な方を選びます。
3498	Re:単なる数値を日付として認識させるには	宮城	1999/11/26-08:55
記事番号3495へのコメントちんぷんかんぷんさん、本題と離れますが、2000年問題はどう考えてますか？このままでは991126となっていた項目が年を越したとたん、101になってしまうんですけど。
3502	Re:単なる数値を日付として認識させるには	宮城	1999/11/26-10:36
記事番号3498へのコメント思わせぶりはやめといて私の対応をご参考までに。西暦４桁表示すべきと考えてますが、表示領域の関係上やむをえないこともあるでしょう。しかし、システム屋としては最低限000101（ぶざまですが）にはしてあげないといけないでしょ。となると桐では文字列にしてあげるしかありません。項目を追加しまくります。項目名が冗長になりますが目をつぶります。以下、追加項目・タイプ・項目計算式とみてください。既存項目が[年月日]数値であるとすれば、 [年月日・２桁年文字列]・文字列・＃文字列（[年月日]，６） [２桁年・数値]・数値・＃数値（＃部分列（[年月日・２桁年]，１，２）） [月・数値]・数値・＃数値（＃部分列（[年月日・２桁年]，３，２）） [日・数値]・数値・＃数値（＃部分列（[年月日・２桁年]，５，２）） [４桁年・数値]・数値・　＃条件選択（[２桁年・数値]＞９５，１９００＋[２桁年・数値]，　１，２０００＋[２桁年・数値]） [年月日・日時値]・日時・　＃日時値生成（[４桁年・数値]，[月・数値]，[日・数値]）表示項目は[年月日・２桁年文字列]に切替え、日時計算には[年月日・日時] を使います。受付日・納期等々、複数ある場合、その分だけやるしかないでしょ。項目名は１０文字まででしたかね。その他は大小判定をチェックしておいてください。あと１ヶ月足らずですよ。
3503	Re:単なる数値を日付として認識させるには	宮城	1999/11/26-12:35
記事番号3502へのコメントすみません、ミスしてます。誤：[２桁年・数値]・数値・＃数値（＃部分列（[年月日・２桁年]，１，２）正：[２桁年・数値]・数値・＃数値（＃部分列（[年月日・２桁年文字列]，１，２）以下同様。だから、冗長な項目名は本当は嫌なんですが。
3507	yymmdd形式の日付データの扱いは	佐田　守弘	1999/11/26-16:17
記事番号3495へのコメントちんぷんかんさん。メインフレームなどから出力されると(思われる)yymmdd形式の２桁年号固定長型の日付データについては、桐に取り込んだ後、日時型に変換して扱う必要があると考えます。その方法については、既にOgoさん、宮城さんからコメントされている方法と同じですが、私なりの補足をさせて頂きます。桐の表には上記形式のデータを長整数として取り込む項目と、これを日時値に変換した項目の２つを用意します。 [元日付]：長整数型 [日時]：日時型そして、[日時]の項目には次の様な項目計算式を設定します。 #日時値生成(#計算(#代入(&件数,[元日付]) ,#代入(&年,&件数%10000) ,#代入(&件数,&件数-&年10000) ,#代入(&月,&件数%100) ,#代入(&日,&件数-&月100) ,#代入(&年,&年+#条件選択(&年<50,2000,1,1900)) ) ,&月,&日) この計算式は、[元日付]を数値として扱い、10000で整数除算して年の値を、剰余を100で整数除算して月、更にその剰余を日とし、「#日時値生成」関数で日時値に変換しております。これは、2000年以降の6桁年号を数値として扱った場合５桁になる事を考慮しての対策です。おそらく、2000年を越しても、西暦２桁日付は使い続けられるだろうと思います。これをパソコンに取り込む際に、2000年問題を起こさない様な値の変換が必要になると考えます。（詳しくは次のコメントで述べます）佐田守弘(KS-00119)
3508	メインフレームとパソコン間で懸念されるＹ２Ｋ問題	佐田　守弘	1999/11/26-16:22
記事番号3495へのコメント西暦2000年問題と桐（メインフレームとＰＣとのデータ交換で懸念されるY2K問題）皆様西暦2000年問題で指摘される来年まで残すところ後１月。世の中では2000年対応がほぼ完了したと伝えられております。桐もシステムとしては2000年対応になっておりますし、おそらく誰もが2000年対応は大丈夫と思っておられるのではないでしょうか。ここでやや爆弾発言的な話になりますが、桐ユーザーに限らず、「メインフレームのデータをパソコンで扱う場合には、2000年問題を改めて考える必要がある」事を述べさせて頂きたいと思います。「今更そんな！対策済なのに」とは思わないで下さい。おそらく多くのメインフレームから出される日付データは、元発言のちんぷんかんぷんさんが言われる様な、２桁年号のyymmdd型が今後とも続くことでしょう。なぜから、本当の意味での2000年問題は対処されていないためです。 ●メインフレームではどの様にY2Kに対処したのか Y2K問題に正しく対処するなら、日付の年号部分を4桁表記すべきでした。これはほとんどのパソコンユーザーがそのように行っておりますし、パソコンユーザーの常識です。おそらく桐のユーザーも年号は既に４桁に変換し終わっていると思います。ではメインフレームではどうだったのでしょうか。おそらく４桁化はされていないと思います。そしてコンピュータ間でのデータ交換のフォーマットも従来通りの２桁方式で行う事で世の中が統一されたのではないでしょうか。 ●なぜ年号は４桁にできないのかパソコンユーザーから見れば不思議な疑問だと思いますが、メインフレームで全データを４桁化する事は、不可能な事だったのではないでしょうか。なぜなら、メインフレームが扱うデータはパソコンの様なCSV形式ではなく、固定位置でデータを切り出す固定長型です。データ通信の代表である全銀協フォーマットでも確かそうなっていたはずと思います。もし勝手に年号部分を４桁にしたら、２桁形式のデータが混在した時に大混雑を起こすはずです。全世界のメインフレームが両方式のデータ形式を用意し、「ヨーイドン」で一斉にデータ形式を切り換える(ディスク上のデータも一瞬に書き替える)事ができれば別ですが、そんな事は不可能でしょう。ですから、年号は２桁方式を踏襲し、使ってない桁位置にセンチュリーフラグを付けて、1900年代か2000年代を区別する方式になったはずだと思います。 ●年号２桁形式のデータがパソコンに取り込まれたらもしメインフレーム側のプログラムが、パソコン用に出力するデータには年号４桁のCSV形式で出力してくれるなら、問題はありません。パソコン側は既にY2Kに対応済みでしょうから、正しい年号で扱えます。しかかしながら、出力されるデータがセンチュリーフラグ付きの２桁年号形式だとしたら、取り込んだパソコン側でデータの扱いの誤りを起こすおそれがあります。メインフレームはパソコン用にデータを出力する事を主目的としているわけではないので、多分にあり得る話です。そのような意味で、ちんぷんかんぷんさんが言われる問題は、他人事ではない様に思います。 ●メインフレームとパソコンとの対処方法の違い結局の所、西暦年号４桁方式の採用や、桐などに見られる日時値型で今後数万年先まで正しい日付を扱える様にしたパソコンと、それができずに年号は２桁方式を踏襲せざるを得なかったメインフレームとの間で、すれ違いが起きている様な気がします。このすれ違いによって、メインフレームとパソコンとのデータ交換において、Y2K問題の発生が懸念されてなりません。結局の所、これが忘れられていた「大きな落とし穴」になるのではないかと思うのですが、皆様方の御意見はいかがでしょうか。佐田守弘(KS-00119)
3512	Re:メインフレームとパソコン間で懸念されるＹ２Ｋ問題	宮城	1999/11/26-17:55
記事番号3508へのコメント私の知っているシステムは一昔以上前のものかもしれませんが、基本的に汎用機とパソコンは別系で、まさにパソコン用データとして作り、パソコンからのデータとして吸い上げるということをしておりますので、 2000年対応の漏れが発生するとはちょっと考えられません。ただ、他は見当のつかないところです。ちなみに今はパソコンのみのシステムを使っています。桐V5での対応は、数値のゼロサプレスをやめられないため、煩瑣を承知で YYMMDD、YYYYMMDD を数値・文字列、都合４項目併存させ、表示は 101回避のため、YYMMDDの文字列に切り替えるものとしています。

戻る