コンピューターの世界では元号に対応をするのは簡単ですが、西暦 2000年になるときに問題が発生する可能性があるので大騒ぎでした。
私が 日本IBM に勤めていたころ西暦 2000年が近づいてきて Y2K（Year 2000）対応でY2K担当部長まで設定されていました。
私もインターネットで接続をする UPS（無停電電源装置） を担当していましたから、UPSメーカーとの対応をしていたのです。
ネットワーク監視のは SNMP（simple network management protocol）という世界標準のネットワーク管理プロトコルを使っていてUPS のSNMPエージェントとサーバーの SNMPマネージャーがY2Kの対象でした。
ネットワーク接続の UPS には、TCP/IP の SNMPエージェントを持っていて、サーバーの SNMPマネージャーが監視をする仕組みだった。画像は WEB から借用した。
昔はコンピューターのストレージサイズが小さかったし、COBOLやFORTRANのような古いプログラミング言語では、データ型に「日付」が用意されておらず、プログラム内では、年を表現するために2桁の文字型を割り当てて、西暦表示4桁のうち下位2桁を記録・処理していたのつかったです。
ですから西暦2000年になると 1900年になってしまいアプリケーションに不都合が生じたのです。
また西暦2000年は「400年に1回」の特殊な閏年で閏日（2月29日）があるのに、その処理をしていないプログラムもあったのです。
現行のグレゴリオ暦では、閏年について次の規則があります。
西暦年数で4で割り切れる年は閏年とする。
1.のうち、100で割り切れる年は平年とする。
2.のうち、400で割り切れる年は閏年とする。
私が担当していた ネットワーク接続の UPS は、ほかのアプリケーションのように細かいものではなく、曜日に対応をすればいいので基本的に対応はできたのですが UPSメーカーが 2社あって確認作業があったのです。
ほかのアプリケーションでは、1989年からの消費税や昭和から平成への改元の対応もあって、アプリケーションにはかなり対応ができていました。
六本木プリンスホテルの中庭にあった温泉プール。バブルの象徴と言われていた。
そのころは本社が六本木3丁目にありましたから、1999年12月31日は隣にあった六本木プリンスホテルに泊まって緊急時の待機をしました。
バブルの象徴と言われていた中庭の温泉プールも実物を見ました。
裕福そうな親子ずれの子供が泳いでいたのを覚えています。
今回、元号が変っても 西暦に変換をするだけですから問題は起きないでしょう。
Y2K の時のようにコンピューターの誤動作の可能性はありませんからね。
結局、何も問題はおこらなくて無事に西暦2000年の新年を迎えました。
エンジニアの時代には、年末年始の仕事は普通だったのですが、Y2Kの時は久しぶりでした。
