
昭和100年と日時の記録
昭和は64年までで平成は31年までありました。そして令和も今年で7年となるわけですが、実は今年まで昭和が続いたとしたら100年となる節目の年でもあるようです。
コンピュータが発明され多くのシステムが作られたのは昭和の時代に当たるので、元号が昭和から平成になる時に、年を記録する部分に元号の種別を持たず年しか持たなかったシステムは平成になった時に年が64より大きい(厳密には特定の日付以降)であれば、それは平成と解釈することで乗り切りました(表示すらそのままで人間が対応しているシステムすらあったようです)。そして令和になったときも同じような対処で済ませたこともあったようです。2000年問題と同じように年を記録するために数字2桁しか用意していないことが普通だったので、今年は昭和0年となってしまい問題が出るシステムがあるのではないかと心配されています。もちろん内部的には整数で扱っているのに困らないにしても表示、印字する時にはみ出したりして書式が乱れることは充分にありそうです。
まあ、そのようなシステムは30年以上メンテナンスせずに来ている訳ですし、多くの場合ネットには接続されていないのではないかとも思われるのですが、機器に組み込まれたソフトなどであると案外、残っている可能性が無いとも言えません。年が0になっても何事もなかったように動き続けるかもしれませんし、システムがクラッシュしても「もう寿命だったんだね」と交換されるものなのかもしれません。
注意する点としては、普段は稼働していない予備機であったり、大事に保管しているものでなにかの折に起動し正直に今の年を初期設定するといきなり壊れるというケースもあるかもしれません。使っていないとどうなるかもわかりませんからね。
昭和100年問題
ちなみに昭和という元号が使われていたのは1926年12月25日から1989年1月7日までで、昭和の両端はそれぞれ1週間ほどしかありません。平成は1989年1月8日から2019年4月30日まで、そして令和は2019年5月1日から現在まで使われています。
元号の切れ目に関しては、昔は今より元号が幅広く使われており、パソコンで日付を扱うために和暦西暦変換処理をよく書いた覚えがあります。ちなみに今の暦の仕組みが使われたのは明治5年以降なので、それ以前の暦に関しては単なる年の置き換えだけではなく月日も計算し直す必要があるので、普通はそれ以前の処理は諦めることになっています。ところが富士通の某ワープロではちゃんとうるう月まで変換して表示されるのを発見して驚いたというよりも少しばかり呆れてしまった覚えがあります。
元号
当時、データベースの内部には西暦で記憶し、入出力で和暦に変換するようにしていたことも多いのですが、和暦のまま元号フィールドを設けて記憶したこともありました。その時代は明治、大正、昭和の3つを扱えれば良かったのですが(既に明治5年以前は諦めていた)、そろそろ昭和も終わりそうだったので予備として次の元号の領域までは予約しておいたものです(変わるのは急なことが普通なので)。それでも人生100年時代にはなっていなかったので、年のフィールドは2桁まででしたね。
日付に関する処理は昭和から平成になる時に、それなりに見直され内部処理を西暦にすることが増えたように思います。そして2000年問題の時にも見直され、扱い方が整備されたように思いますが、統一的な日付処理がどのシステムにもあるわけではなく、データベースでも日付の処理がマチマチなのは今でも残っていると思います。細かなことを言えば2100年問題(この年はうるう年ではない)であるとかうるう秒の扱い(今後、どうなるかは決まっていない)、日常的にはタイムゾーンとサマータイムなど(それに世界には暦はたくさんある)、いい加減にしろという問題がたくさんあります。いっそのこと世界中で統一した標準時を使って、それぞれの地域の活動時間をそれぞれにした方が世の中ラクになるのではないかとも思うくらいです(日本では9時始業が増えるのでしょう)。
そういえばプログラミング言語における日付と時刻の取り扱いについても、いくつか思い出してみますか。
ヘッダ画像は、AIによる生成です。
いいなと思ったら応援しよう!
