一般にはあまり関係ないことですが、コンピュータ業界にとってプログラムの修正がいくつか出てきます…特に公文書系の書式フォーマットは元号の入った規定用紙を使用した作りとなっているので、システム内の用紙変更が必須。また、4月1日には裏設定で元号←→西暦の変換テーブルに「新元号=2019(実際は1900年から2019年5月1日までの総日数)」の書換をいくつか行うことになります。 |
 |
コンピュータに携わるものとして和暦計算に以下の数字は敏感に反応します。
・明治5年(1872年)12月2日までは旧暦、1873年1月1日(旧暦12月3日)より現在の和暦明治6年1月1日スタート。
・1900年(明治33年)1月1日、主にパソコン内の0日基準→経過日数が分かります。システムによって違う。特別な閏年。
・1904年(明治37年)1月1日、主にパソコン内の0日基準→経過日数が分かります。システムによって違う。通常閏年。
・1970年(昭和45年)1月1日、UNIX時間(UTC)の0秒基準→経過秒数が分かります。ちなみに日本時間(JST)は+9時間。
一般的に和暦は明治以降を扱うので1900年(または1904年)1月1日を基準にコンピュータから知りたい日までの経過日数を得ます。
・大正元年(1912年7月30日)は1900年から4,593日。
・昭和元年(1926年12月25日)は1900年から9,854日。
・平成元年(1989年1月8日)は1900年から32,514日。
・令和元年(2019年5月1日)は1900年から43,584日。
プログラム的には「知りたい日の経過日数をコンピュータから教えてもらい4,593未満なら明治、9,854未満なら大正、…と順番に処理し、43,584未満なら平成、どれにも当てはまらない場合は令和」と処理する。 |
 |
ちなみに、西暦元年からの経過日数は以下の式(フェアフィールドの公式)でも求められます。
・4の倍数の年は閏年。
・ただし、100の倍数の年は閏年ではない。
・しかし、400の倍数の年は閏年。
の規則に従い、近似値直線の整数グリッドを上手に利用して、dm =| ( 306 m -324 ) / 10|→dm =| ( 979 m -1033 ) / 32|を活用して求められます。
参考のためCのプログラムで記述すると、
int GetDays(int y, int m, int d){
if (m <= 2){ --y; m += 12; }
int dy = 365 * (y - 1);
int c = y / 100;
int dl = (y >> 2) - c + (c >> 2);
int dm = (m * 979 - 1033) >> 5;
return dy + dl + dm + d - 1;
} |
|
で、次回問題になるのは、「明・大・昭・平・令」という公文書で良くある選択肢。
このうち「明」の字をいつ消すのか？問題です。
つまり、今消すわけにはいかないけれど10年以外には消すことになると思います。要するにあと数回は地道に公文書の書式変更があるということです。 |
|
|
|
2000年問題
西暦の下2桁で年を判定していたシステムは1999年(99)→2000年(00)の瞬間にシステムが1900年だと思うことで不具合が出ると予想されました。
特にマイナス年の扱いができていないシステムは何が起こるか分からなかった。
うるう秒
地球の回転とのズレでうるう秒として1秒追加されるときがあります。
例えば2012年7月1日午前9時(JST)、2015年7月1日午前9時(JST)など。
一部パソコンソフトで0時をまたぐ使用方法で間違った値を返すという不具合が報告されています。
2038年問題
2000年問題より深刻で、理由としては上記UNIX時間のシステム制限値(2,147,483,647秒)を超えてしまうことです。
つまり、1970年1月1日からの秒数が2,147,483,647を超える日が2038年1月19日3時14分7秒(日本では2038年1月19日12時14分7秒)ということです。これは現在の多くのコンピュータの値を扱う部分の上限値LONG型の最大値で2,147,483,647を超えると負数となります。
ただし、64bit-Timeを使用している場合は9,223,372,036,854,775,807秒で西暦3,000億年まで使用可能です。 |
|
|
|
|
|
|
|
|
|
|
|
