Access開発サポート

コンピュータで日付やカレンダーを扱う場合、
今後、起きうる問題として、2038年問題という問題が浮上してきています。

32ビットで日付を扱うと起きうる問題

ここでは詳しい説明は割愛しますが、
簡単に言うと、
日付が2038年1月19日3時14分7秒を過ぎると、
32ビットのデータ容量を超えてしてしまい、
コンピュータが誤作動する問題のことです。

筆者は以前、Accessではありませんが、
UNIX系のシステムで、この問題に遭遇したことがあります。

Accessには32ビット版と64ビット版がありますが、
このうち、32ビット版のAccessの方が気になったので、
検証してみました。

Access2019の32ビット版で検証

問題となる2038年1月19日3時14分7秒を過ぎる前と、
過ぎた後の日付を入力してみたところ、
結果、
Accessでは何も問題なく、入力、表示できました。

※2038年問題が起きる前後の日付で、問題なし

それもそのはずで、
Accessで扱う日付のデータ型「日付／時刻型」は、
古くから、64ビットで統一されているためです。

これでAccessで2038年問題は発生しないことが分かりました。

Accessでどこまで日付が入力できるの？

せっかくなので、Accessでどこまで日付が入力できるのか調べてみました。

※Accessは西暦100年から9999年まで入力可

現実的に使用される日付の範囲はすべて問題ないといえるでしょう。

さらに、和暦でも入力してみたところ、入力可能な最後の日付は、
西暦9999年と同じ年にあたる、
令和7981年まで入力できました。

これは、
Access内部で保持される日付データが西暦年であるためと思われます。

※令和7981年まで入力可（Access内部では西暦9999年）

まとめ

よくよく調べてみると、
2038年問題が起こるのはUNIX環境が主ということです。

今回、検証した結果のとおり、
Windows環境で動いているAccessについては、心配なさそうです。

和暦の場合は、
「令和7981年」まで入力可能ですので、ご注意ください。

関連記事

Access2007以前は「令和」に対応していません

トゥさん

大手SIerに長年常駐し大規模システムの経験を重ねプログラムスキルとDB設計を磨く。AccessおよびExcelのVBAを得意とする。

⇒お仕事のご依頼はこちら