コンピュータの時間の扱いについて、いろいろ聞かれることがあります。これ結構奥が深いんです。で、何故そうなっているかを知るにはいくつかの背景を知っておく必要があります。それに加えて、暦は結構面白い話が多いので、まとめてみました。

太古の大昔から、人間にとって暦は極めて重要な概念として使用されてきました。暦は主の以下の4つに分類されます。

今われわれが使用している暦は、グレゴリウス暦です。これはいい暦なんですが、問題というか逸話が多いんです。

英語圏の方々が使っている月の表記名に人の名前が入っていることは有名です。2月は閏年の調整日として使われます。30日と31日の並びが規則性がなんか中途半端です。これらがなぜかは、はるか昔、ローマの時代までさかのぼらなければなりません。

紀元前753年に建国されたローマ（ロムルス王）では1年を10ヶ月304日とする太陰暦が使用されていました。今で言う、3月から12月までの10ヶ月です。実際はこうなっていました。

3月が始めだったのは、その時期が春だからです。実は1年の最初は春分の日に一番近い新月の日というアバウトな暦でした。そして、その前の冬の約6１日間は日付もつけずただひたすら春を待つという過ごし方をしていたようです。

が、そのうち、やっぱり日付がないのは不便だということで、ユマ王時代（紀元前710年：実在しなかったという説があります）に2か月分追加することになります。が、月の満ち欠けの12倍という決め方をしたため、1年が355日でした。ローマ人は奇数を吉としたことから、1ヶ月は29日間（4ヶ月）か31日間（7ヶ月）で、最後の（と思い込まれていた）Februariusだけが28日間という設定になっています。

名前から分かるように本来Januariusは最初の月として制定されたのですが、慣習的にはDecemberの後に2つの月が追加された（すなわちFebruariusが年末である）形で運用されていました。その証拠に、ユマ暦ではずれを調整するための閏月をFebruariusの23日の後に設けています。なおFebruariusの23日は1年のしめくくりの祭り「テルミナリア」（日本でいう大晦日でしょうか）の日でした。

次に、紀元前46年に、ユリウス（かの有名なジュリアス・シーザー[Gaius Julius Caeser]です。）は、天文学者に命令して新しい暦であるユリウス暦を導入します。彼が政権を握ったとき、実際の暦と季節のずれは3ヶ月以上になっていたため、全面的に暦の改訂を行いました。太陽暦を採用し、奇数月を31日（大の月）、偶数月を30日（小の月）と定めました。分かりやすくていいですね。が、こうすると一年が366日になるため、1日分調整する必要がありました。それで、慣習上の年末であったFebruariusが調整の対象となり29日になります。ところが、同時にJanuariusが最初の月であることを再度指定した（これにより、以降の暦ではQuintilisより後の月が本来の意味から2つずれるという現象が発生します。後述する理由によって、現在ではSeptember[7]からDecember[10]のみがずれて残っていますね。）ので話がややこしい。まあ、ヤヌス神が最初じゃないのはまずいと判断したんでしょう。これが、年末でもない2月が閏日の調整日とされる理由です。ちなみにユマ暦の年始が春分（現3/20前後）近くなので、年始は現在の1/20ぐらいに相当しています。

なお、ユリウス暦は古代エジプト暦を参考に制定されました。古代エジプト暦は、1年を12ヶ月に分け、1ヶ月を30日として、残りの5日を12月の終わりに付け足したというものでした。その後、1年が365日5時間48分46秒であることを知り、4年目ごとに1日を加える「うるう」の方法を発明していました。その方法とは、調整のために3年（365日）は平年とし、その後に1年閏年(366日)を導入するというものでした。

ちなみに、ユリウス暦ではユマ暦での閏月と同じFebruariusの23日（ユマ暦の年末祭：テルミナリアの日）のあとに閏日を入れました。このため、Februariusの23日と24日の間に閏日が入るというへんてこな閏日になってしまいました。

このとき冬至からすぐの新月を紀元前45年 1月 1日にし、紀元前46年を445日にして調整しています。

こころへんは良かったんですが、カエサルともなると、わがままの桁が違います。自分の誕生日があったQuintilisを自分の名前Juliusに変えてしまいます。すごいですねー。

カエサルはその後暗殺（”ブルータス、お前もか！”で有名ですね）されますが、ユリウス暦はこの後約1600年の間使用されることになります。が、ここで問題が。最初の頃、ローマ語の習慣上の問題で、”3年平年の後に1年閏年”が”3年毎に1年閏年”と誤解されて運用されます。これに気付いたローマ帝国初代皇帝アウグストゥス（Gaius Julius Caesar Octavianus, Augustus Caesar）は、B.C.6年からA.D.8年までの13年間（実質3回）閏年をいれずにずれを修正するということを行っています。もともとAugustusは”尊厳者”という意味で、ローマ元老院からオクタビアヌスが受けた称号です。

名前から分かるように、オクタビアヌスはカエサルの甥です。親戚譲りといいましょうか、大胆不敵なことをやってのけます。アクティウムの海戦でアントニウスとクレオパトラを破りエジプトを滅ぼした大勝利を記念して、暦を改正したときに自分の名前を残したいと考えたのです。で結果的に、SextilisをAugustusに変えてしまいます。そのときに、Sextilisは小の月で30日しかないのは納得いかない！という理不尽な理由で、Augustusを大の月（31日）に変え、以降小の月と大の月をずらしてしまいます。（したがって、Augustus以降は、偶数月が31日、奇数月が30日となります）また、こうすると1年が366日になってしまうので、Februariusから更に1日もぎ取ってFebruariusが平年で28日となりました。

こうしてみると、Februarius=2月って、受難の月ですね。まあ、その代わりといってはなんですが、他の月に比べて非常に特徴はありますが…。

ユリウス暦が採用された頃、ローマではミトラ教という宗教が最大派閥でした。その宗教の主神である太陽神ミトラは冬至に死に（=太陽が最も低くなるjその3日後に復活するとされていました。その復活日はローマの最大の祭りである冬至祭にあたり、復活祭と冬至祭が重なったその日は実に盛大な御祭が行われたそうです。これが、実は12/25なのです。その後ミトラ教は衰退し、代わりにキリスト教が広がりを見せていくのですが、その際この祭日が受け継がれることになります。これにより12/25がキリスト教の祭日すなわちキリスト生誕の日（教義上の意味合いから降誕日といわれるようです。実際のキリスト生誕日ははっきりしていません）となります。

おいおい、そんなのでいいんか？と思うかもしれませんが、いろいろな宗教でこのような風習を受け継ぐということはよくあることのようです。これがクリスマスの起源ですが、実際にA.D.325年のニケア公会議で12/25がクリスマスとして公式に認定されています。なんで、クリスマスの話が出てくるかというと、西暦の成立とは密接な関係があるからです。避けては通れないんですよ。

この頃の年号はローマ紀元とよばれるディオクレティアヌス紀元や、キリスト受難の年を基準とした紀元などを採用していました。当時最も浸透していたディオクレティアヌス紀元では、ローマ皇帝ディオクレティアヌス（Gaius Aurelius Valerius Diocletianus）の即位の年（A.D.284年）が紀元年とされていました。が、ディオクレティアヌスといえば、キリスト教迫害で有名な皇帝です。これに反発する意味合いで、新しい紀元がA.D.531年、イタリアのとある修道院の院長ディオニュシウスによって提唱されます。彼はキリストがユダヤ教の割礼を受けた日、すなわち生誕日（12/25）から8日目を紀元としました。彼が東ローマ帝国の修道院長であり、天文学と数学に精通していたこともあって、この暦が東ローマ帝国で採用されることになります。なお、このときにA.D.という呼びかたも決められました。A.D.とは、ラテン語で「我らが主の年」を意味する、Anno Domini （A.D.）のことです。なお、この考え方のことを「割礼年初」といいます。

しかし、どういう訳かこのキリスト生誕紀元はなかなか広まらず、10世紀になってやっとヨーロッパ全体に行き渡ったそうです。さらにヨーロッパでもキリスト教圏でない地域では14世紀になってからというように、非常にゆっくりしたペースで広まったということでした。ちなみに最初、紀元前はラテン語で”キリストの前”の意味のAnte Christum （A.C.）となっていました。これに対し、B.C. (Before the birth of Christ)という記号が使われるようになったのは、さらに時代がたった17世紀のことだそうです。で、A.C.って、After Christではないんです、ややこしいですね。

今では世界中ほとんど全ての地域で共通の年号として定着しているA.D.とB.C.ですが、実はディオニュシウスが提唱したキリストの生誕日というのは間違っているそうです。現在でも正確な日時というのは明らかになっていませんが、真の生誕は紀元前4〜5年頃だったのではないか、というのが定説です。まあ、これだけ浸透してしまったので、いまさら変更するわけにもいかないということでしょうが、今の西暦の紀元って本当は何があったんでしょうか？ちょっと気になります。

16世紀にはいるとある程度正確であったユリウス暦でも約12日間のずれが生じていました。キリスト教徒にとって最も重要な意味を持つ日としてイースターすなわち復活（感謝）祭があります。復活祭は春分の後の最初の満月から最初の日曜日（ここらへんは古代ローマの慣習が色濃く残っていることがよく分かります）と決められていました。我々日本人には理解しがたい感覚かもしれませんが、キリスト教徒にとってその基準となる春分の日を正確に暦と一致させることは至上命題だったのです。これに対し、時のローマ教皇グレゴリオ13世はこの問題を重視し、1582年に暦の改定に着手します。これによって策定された暦がグレゴリウス暦です。この暦は、

1. 1年を365日とする。
2. 西暦年数が4で割り切れる年を閏年とし、2月の末日に29日を追加する。
3. 西暦年数が100で割り切れる年は閏年を適応しない。
4. 西暦年数が400で割り切れる年は3の条項を無視し、閏年とする。

というものです。実は、これまでの時点で3まではユリウス暦に取り込まれていました。グレゴリウス暦において4の条件が加わったことになります。

グレゴリウス13世は、1582年10月4日でユリウス暦を打ち切り、10月5日を新10月15日としてグレゴリウス暦を施行しました。したがって、実は1582年の10月5日から10月14日までの日付は存在しません。

紆余曲折いろいろありましたが、以来現在までグレゴリウス暦が使用されています。

なお、制定当時カトリックとプロテスタントが激しく対立していたために、グレゴリウス暦はなかなか普及しませんでした。ローマ法王庁に忠実なカトリック国家はすぐにこの新しい暦を採用しましたが、プロテスタント国家は反発してユリウス暦を使い続けました。ヨーロッパ全体にこの暦が広まったのは18世紀後半です。ちなみに、日本では1873年（明治6年）に採用されています。

現在のコンピュータで最もよく使われている時間は世界協定時間を基準とするシリアル値でしょう。これは、現在使用されているOS（Windows・Mac・Unix等）の多くが1972年に開発されたC言語をベースとしたプログラムであることが最も大きい原因であると考えられます。

このC言語での時間の計算方法は、”1970年1月1日0時0分0秒（世界協定時間：UTC）から、何秒経過したか”という表現を使い、時間に関する処理は全てこの秒数を計算して行っています。なお、32bitで表現されています。

実はここに西暦2038年問題の鍵が隠されています。この方式の最大時間は31bit分、すなわち2³¹=2147483646 秒であり、UCTからの経過時間に直すと2038年1月19日3時14分7秒に相当します。その1秒後には計算不能となるというのが西暦2038年問題です。こいつは厄介ですが、まあでも今から40年近く未来のことですので、そのときにはそんなことが問題になるようなコンピュータは博物館ぐらいにしかなくなっているでしょう。

ちなみに、残りの1bitは何をしているかというと、負数を扱うためにあります。なぜって、こうすると1970年からさかのぼって1901年12月13日20時45分53秒までを扱うことができるからです。結果的に、2³²秒=約136年間の時間を扱うことができます。

なお、インターネットでの標準的なシリアル時間は基本的にこの方式だと思っていいです。

ExcelやAccessといったWindowsアプリケーションでは、最近は西暦9999年までの日付をサポートしています。これは、OSとは別にソフトウェア的に日付を処理することで実現されています。このとき使われるシリアル値はUTC基準でなく、また経過秒でもない独自の形式を取っています。基点は1900年1月0日0時0分0秒です。ん、0日ってなんじゃい？と思われるかもしれませんが、このような仕様なので（文句があるなら某MS社まで）しょうがありません。ということで、1以下のシリアル値はおかしな結果（ありもしない日付が表示される）を生みます。1899年12月31日を作るのが死ぬほど嫌だったんでしょうね。1899年は12月31にだけ使えるというのも変と考えたんでしょうか？謎ですね。

ちなみに、一般的な概念で分かるように書くと、1899年12月31日0時0分0秒を基点とした経過日数で表現されます。1日が単位？じゃ時間とか秒はどうするの？という疑問が湧くと思いますが、これらは小数で表します。1時間（１/24=0.04166666…）1分（1/24/60=0.000694444…）1秒（1/24/60/60=0.000015740740…）という具合です。ですので、実はミリ秒[1/1000秒]のような時間を取り扱うことが可能（現在はある特殊な状況でしかサポートされていません。精度の問題があり、普通に使えるようにするのはまずいという判断ではないかと考えられます。）です。システム時間のようにカウンタで管理されていると小数を使うというのは結構いろいろな問題が出てくるのですが、なんせソフトウェア的に処理しているので、何でもありなんです。

このような方法を用いることで、1900年1月0日？から9999年12月31日までの日付をサポートしています。じゃ、1900年1月0日より前はというとサポートしていません。この理由は、従来からの互換性の問題だとか、もともとそんな日付使わないだろうと判断したとかいろいろ理由が考えられます。

好意的に考えると、こう考えられます。これまでずっと書いてきたように、現在のグレゴリウス暦は西暦元年でなく、1582年10月15日から始まっています。本来のグレゴリウス暦にのっとって暦を解析すると、1582年10月15日以前は歴史上の暦と異なった日付になってしまいます。それも数日ずれるような微妙な違いで。（たとえばグレゴリウス暦で1582年10月15日の1日前は1582年10月14日ですが、ユリウス暦では1582年10月5日にあたります。）歴史解釈上どちらの暦を使うかはある種哲学的な問題であり、現在から単純なグレゴリウス暦の規約によって日付を解釈するということには問題があります。なので、少なくとも基点を1582年10月15日以降にして、過去にさかのぼれないようにすれば、この問題は回避できます。で、きりのいいところで1900年にした、というものです。まあ、数学的にはグレゴリウス暦を紀元前まで適応することが可能ですが、そうなるとますます歴史との不一致（前に書いたように、昔はいたるところでイレギュラーな暦の改訂が行われていました。）が出てきますし、日付処理のためのアルゴリズムも紀元前が出てくると複雑になりますからね。使えないようにしておいて、そっとしといた方がいいのかもしれません。（本当にここまで考えて制定されたかは知りませんが）

基準点を定めて経過日数で表現し、小数を使って時分秒を表現するというのはWindows系と基本的に同じです。が、こちらの基準点は1904年1月1日0時0分0秒です。1904年、なーんか、中途半端ですね。何でなんでしょう。

これを理解するにはMacのハードウェアの仕様から考えなくてはいけません。Macのシステム時間を管理するためのクロックチップは32bitカウンタで、1秒おきにカウントアップしていきます。ちなみに32bitの秒カウンタで表現できる時間は約136年間（100年以上動作するコンピュータというのは現実的にありえないのでシステム時間の制御という観点では32bitもあれば十分です。ただハイエンドのミニコン等では64bitカウンタを使っているものもあります。ちなみに扱える年数は、ミリ秒カウンタ[1/1000秒単位でカウントする方式]として5．85億年、カウンタがフルになったときは人類滅亡してそうですね）ですので、2040年2月6日6時28分15秒までは表現できます。もとい、2040年までしか考慮しなくてよいということになります。

さて、グレゴリウス暦をよく思い出してください。4で割り切れても閏年にならない年が1900年と2100年ですね。2000年は400で割り切れるため閏年になります。そうするといかがでしょうか、1901年から2099年までの間であれば、グレゴリウス暦に完全に準拠しても4で割り切れる西暦が全て閏年となっているわけです。Winのように1900年（閏年が適応されない年）が含まれているとこうはいきません。ということで、Macでは特殊な処理を必要とする1900年を避けてその次の閏年である1904年を基準点にしたのです。こうすれば一番最初と一番最後の年がどちらとも閏年になるというおまけつきです。1月1日を基準点にしたのも、1月0日という例外処理をなくす意味（それ以上に、それが常識的だったからという見方もありますが）でしょう。

それならUTCを基準にしても同じではと思われるかもしれません。が、閏年演算は同じでも時間の演算に正数と負数の2つが必要になる場合（C言語）と正数だけでいい場合（Mac）では、正数だけの方がよりアルゴリズム的に簡単に済みます。

なお、WinとMacでは基点が1日ずれています。なので、例えばシリアル値が1の場合、Winでは1月1日を指しますが、Macでは1月2日を指しています。間違えないでください。

このように1904年とは、日付に対するシステムリソースの制限をうまく生かし、かつ日付に対するアルゴリズム（閏年や演算）を可能な限り簡略化するという観点で採用された基点です。

なお、これから分かるように1900年を基点とするシリアル値と1904年を基点とするシリアル値は、表現形式が全く同じであるにもかかわらず基点が異なるため、互換性がないにもかかわらず使えてしまったり（もちろん値はずれますが）します。したがって、MacとWinでデータをやり取りする場合は注意が必要です。なお、Officeアプリでは、この2つの基点を切り替えられるようになっていますが、それぞれネイティブなモードで使用し、データを移し変えるときに変換するようにするのがいいと思います。でなければ、絶対トラブります。

Macのところで、32bitカウンタという話がありましたが、パソコンやマイコンなど、多くの機器がある限られた回路（ちょっと語弊もありますが、ある機能を実現するために必要なシステム資源の事をリソースといいます）を時間管理などに使うことになります。この前、128MBのメモリが2000円で売っていましたが、昔は1MBぐらいのメモリでも軽く数万円していました。総メモリが64kBという今から考えたらごみみたいなメモリしか使えない時期（もちろん、これ以前はもっと悲惨だったわけですが）もありました。現在でもこのような事情があります。特に家電に使われるマイコンチップなどは、1円でも値段を下げることで大きな利益を生みます。なるべく回路をコンパクトに作ることで、これが実現できるわけです。

こうなると、如何に少ないリソースで欲しい機能を実現するかというのがエンジニアの腕の見せ所になります。で、時間の話に戻しますと、たとえば西暦を扱うときに最後の2桁だけ使用するという事になります。1980年を80年とかですね。で、この方法は、データベースを入力する際に労力が軽減されるという利点もあり、非常によく使われました。単に表示だけであればいいんですが、データ処理にもこの方法を使用すると問題が生じます。例えば97年の4年後は101年となりますが、2桁で処理すると01年もしくは、アルゴリズムによっては全く違う2桁の年号になってしまいます。もちろん4桁で処理すれば2001年となるはずですが、1901年も2桁表示すれば01年です。こうなると何がなんだかわけが分かりませんね。もうお分かりだと思いますが、これが2000年問題です。

この2000年問題ですが、大騒ぎしたわりにほとんど何もなかったですね。そのかわり、都市圏のホテルというホテルは満杯、お節弁当も売れに売れまくったらしいです、法人向けに。それだけではありません。家電製品やソフトウェアも含めて、10年くらい前から対策が講じられてきました。ソフトウェアについてはあとからいくらでのケアできますが、ハードウェアに起因する問題は治しようがありません。ですので、一番心配されたのは家電や工業製品に大量に使用されていたチップでした。身近で目に見えるものでは、テレビや炊飯器、Faxなどの日付機能ですね。これらは早期に切り替えるという方法しかありません。とはいっても、このようなチップで使用される時間は暦と関連しているものは少なく、かつシステム全体に影響するものではないので、問題は少なかったようです。より深刻な問題を引き起こすといわれた金融や交通、電力システムなどではソフトウェアの問題がより大きかったと思いますが、結果的にはこちらも問題なく事なきをえたというところでしょうか。

さて、我々日本人は西暦のほかに和暦を使いますね。こうなると更に複雑です。03年となると、明治3年／大正3年／昭和3年／平成3年／1903年／2003年どれだか分かりませんね。一般的には和暦は規則性が悪いため、データ処理には西暦（もしくはシリアル値）を使い最終的に出力するときに和暦に変換するという事をやります。Officeアプリではこれらの年号を扱えますので、問題は少ないでしょう。が、入力の際は西暦であれば4桁入力を行うことをお勧めします。でなければ、表示は必ず4桁西暦か和暦表示にしておきましょう。今ではハードディスクも格安で売っていますので、データを格納する場合も4桁で保存する方がいいでしょう。

さて、2000年問題がリソースと時間の扱いに起因するということが分かると、同じような問題がまだありそうな気がしますね。実は今年もあるんです、2001年問題。2001年9月9日問題とも言われています。先ほども書きましたが、インターネットでよく使われている1970/1/1を基点とする秒単位のシリアル時間[整数型]を使っていると、2001/9/9 1:46:39(GMT)⇒999999999となります。当然、その1秒後は、2001/9/9 1:46:40(GMT)⇒1000000000となり、シリアル秒の桁が一つ上がります。どおってことないように思えるかもしれません（普通はどおってことありません）が、仮にプログラムのなかでシリアル時間を9桁固定で扱うようなことをしているとアウトです。ちなみに、次11桁になるとき（計算上は2286/11/20 17:46:39）にも同じ問題が起こりそうですが、その前に2038年問題がきます。ちなみにGMTとはGreenwich Mean Time：グリニッジ標準時ですので、日本では9時間の時差があります。

当然ながら、2038年問題のような根幹に係わる問題ではないので、問題にされない場合が多いのですが、お行儀の悪いプログラム（つうか、今時普通はシリアル使ってるのに桁固定なんてやりません。）はこれでちゃんと動作しなくなります。で、MS Officeですが、基本的に時間のシリアル値の扱いが異なるので問題はありません。（Windowsのシリアル値[浮動少数型]の特性上、固定桁でプログラミングすることはないと考えられます。）

いかがでしたか？なかなか奥が深いのが分かっていただけましたでしょうか。コンピュータの一つの大きな特徴として厳密性が挙げられると思います。コンピュータを使えば厳密な暦を作ってくれます。が、実際の暦は季節を元に作られるべきであり、その基準は地球の公転周期にあります。一方、現在の時間は原子の電磁波との共鳴周波数で決められています。こちらの方が揺らぎがなく厳密だからです。こうなると、地球の公転との整合性が問題になってくるのですが、実はこの公転周期は微妙に揺らいでいます。現に今でも多少遅くなっていまして、そのため閏秒という調整まで行われています。それに、過去の歴史が複雑に絡んでくるため、やはり一筋縄ではいきません。恐らく、人類が地球を離れて活動するようになると、完全に原子時計を使った暦（紀元が何になるかは気になるところです）が決められるんでしょうけど、それまではいろいろあるとはいえ、今の暦を使いつづけていくことになるのでしょうね。

Back to Home