Windows95/98/Me/NT4.0/2000共通の話題
VBの2001年問題？
●「VB」とは？ マイクロソフト社が提供しているソフトウエア（プログラム）です。 「Visual Basic（ビジュアル ベーシック）」というソフトです。 略してVB（ブイビー）と呼ばれることがあります。 VBは、「ソフトウエアを作る為のソフトウエアです」．．．．（＾＾；）。 ちょっと、ややこしいでしょうか。 「ソフトウエアを作る為の、コンピュータ言語」、 「コンピュータの世界で使われている言葉」といったほうが、 わかりやすいでしょうか？ コンピュータ言語には、「アセンブラ」、「ＣＯＢＯＬ」、「Ｃ言語」等 いろいろな種類があるのですが、その一種類です。 例えば会社で使う、業務用のソフト、例えば売上入力とか、仕分伝票入力とか、 そういったソフトを作るのに使われたりします。 また、フリーウエアとかシェアウエアの中にも、VBを使って作成されている ものがあります。 ●「2001年問題」？ VBを使って作られているソフトが、問題を起こす可能性があるのですが、 必ず起きるわけではありません。VBの使い方によっては、2001年問題というのが 発生するということです。 VBの内部的な問題で、日付が正しく処理されない場合があるのです。 ●「2001年1月2日」が「2002年1月1日」に（＾＾；）、、、？ 例えば、「2001年1月2日」のつもりが「2002年1月1日」として、扱われてしまう 可能性があります。 「2001年1月3日」は「2003年1月1日」、 「2001年1月4日」は「2004年1月1日」、 「2001年1月5日」は「2005年1月1日」．．． のように解釈されてしまう場合があるのです。 「何ソレ？どういうこと？」．．．って（＾＾；） ●ＶＢは「MM/DD/YY」或いは「MM/DD/YYYY」が標準 VBは、もともと、アメリカのマイクロソフト社が開発した製品です。 アメリカでは日付を扱う場合、 「MM/DD/YY」或いは「MM/DD/YYYY」の順で表記するのが一般的です。 例えば、1999年3月15日は「3/15/99」或いは「3/15/1999」です。 「YY/MM/DD」或いは「YYYY/MM/DD」の形式、 「99/3/15」や「1999/3/15」は、きわめて日本式なのです（＾＾；）。 VBの中では、日付を設定するときに＃（#マーク）が使われます。 アメリカで、VBを使ってソフトを作る人は、 1999年3月15日を #03/15/99# 或いは #03/15/1999# のように書きます。 でも、日本でソフトを作る人は、 #99/03/15 或いは #1999/03/15#のように 書きます。 VBの世界では、本当は、日本でもアメリカ式に書かないといけないのです。 MADE IN USAのソフトですから（＾＾；）。 2001年について、日本式に記述すると、どう解釈されるかですね。 #01/01/01# ．．．これは2001年1月1日と解釈されます。問題ありません。 #01/01/02#．．．これは、2002年1月1日と解釈されます（＾＾；）。 2001年1月2日は VBでは #01/02/01#若しくは #01/02/2001#と書かないと だめなんです．．．。 #01/01/03#は2003年1月1日．．．。 1月1日は問題ないのですが、早ければ1月2日から誤った解釈が 発生する可能性があります。 ●1999年や2000年は大丈夫でした VBでは、#99/03/15# の記述があると、「2015年99月15日」となるので これは、不正な値、誤った値と判断します。 ただし、不正な値と判断された場合は、次に日本的な解釈を試みるのです。 先ず「MM/DD/YY」の形式で判定、次に「YY/MM/DD」の形式で判定。 ですので、#99/03/15#と書いても「2015年99月15日」ではなくて 「1999年3月15日」と解釈してくれます。 #00/12/31#の記述は、「2031年00月12日」ではなくて 「2000年12月31日」と解釈されます。 「なら、日本式で問題ないジャン！」って．．．（＾＾；）。 ＶＢでは、1999年も2000年も問題は発生しないのですが、 2001年では問題が発生するんです。 月(MM)の値が不正な場合は、日本式な解釈を試みてくれるのですが 月の値が不正でなければ、日本式な解釈はしてくれないのです。 本当は、アメリカ式の解釈しかしないのが原則なんです。 ●問題が発生する書き方と発生しない書き方 【問題の発生する記述例】 #(YY)/(MM)/(DD)#形式 #00/12/31#．．．問題なし。2000年12月31日の解釈 #01/01/01#．．．問題なし。2001年1月1日の解釈 #01/01/02#．．．問題発生。2002年1月1日の解釈 #01/01/03#．．．問題発生。2003年1月1日の解釈 【問題の発生しない記述例】 #(YYYY)/(MM)/(DD)#形式 #2000/12/31# #2001/01/01# #2001/01/02# #2001/01/03# #(MM)/(DD)/(YY)#形式 #12/31/00# #01/01/01# #01/02/01# #01/02/01# #01/03/01# #(MM)/(DD)/(YYYY)#形式 #12/31/2000# #01/01/2001# #01/02/2001# #01/02/2001# #01/03/2001# ●ACCESS(アクセス)でも同様の問題が（＾＾；） VBはお使いにならなくても、マイクロソフト社のアクセスをお使いの方は けっこういらっしゃるのかも．．．。 VBと同様に日付の問題が発生する可能性があります。 ●日付の計算や判定は深刻な問題かも．．． 単に、日付が間違って表示されるだけなら、大きな問題ではないかも しれません。 でも経理上の伝票日付がとんでもない日にちで処理されたら、大変ですね。 2001年1月4日の入金が、2004年1月1日の入金に扱われたら（＾＾；）、、、。 日付でデータの参照や突合をするときも、データは存在するのに 「該当データなし」と誤って判定されると困りますね。 日数計算（期間計算）も、とんでもない日数が算出されると、 利息が違ったりして困ります．．．．。 ●マイクロソフト社のサイトでご確認を さらに詳しくお知りになりたい方は、 下記マイクロソフト社のサポート情報をご覧ください。 ・[ACC2000]yy/mm/dd 日付を#で囲むと"mm/dd/yy"に変換される ・[VB] 日付リテラルにより日付を設定するときの注意 ・[VB] 関数から返される日付の書式について （2000年12月21日） 「動け！Windows 」 Home ＞ 2001年問題？ |