macroscope

( はてなダイアリーから移動しました)

日付・暦の情報のあつかいに関する覚え書き

バベルの塔の職人長屋

【まだ書きかえます。どこをいつ書きかえたかを必ずしも明示しません。】

- 1 -
歴史記録の情報を、歴史学者、自然科学者を含むおおぜいが共同利用するための情報基盤を整備しようという仕事にかかわることになった。

そこで、記録内容の日付情報をどう保有するか、どう検索するかが問題になる。

ここで想定している共同利用の対象は、日本の(先近代と近代にわたる)歴史的資料だ。そこで、ひとつの西暦 (太陽暦)と ひとつの和暦 (太陰太陽暦)を、相互変換をふくめて、使えるようにしようとしている。

そこで出会ったこまごまとした問題点についての覚え書きを、ここに書いておく。じゅうぶんな調査をしたわけではなく、情報源は、すでに知っていたサイトとWikipediaにたよったところが多い。確実な知識の提供にはなっていないことをおことわりしておく。

- 2 -
西暦の必要性は、自然に関する面で、地球の公転によっておこされる自然の季節変化のなかでの位置がわかるようにしたいということと、人間に関する面で、世界各地域間の対比をしたいので、そのための便宜上の標準として西暦を採用したい、ということがある。

自然の目的だけならば、太陽との位置関係(夏至・冬至の日付など)がずれていかないように、平均の1年の長さをなるべく正確にしたい。それには、グレゴリオ暦が制定されるよりもまえもさかのぼってグレゴリオ暦を使ったほうがよい。それは気象・海洋関係の数量データのメタデータ標準である「CF Convention」(Eatonほか, 2017)の4.4.1節 "Calendar" で「ptoleptic_gregorian」と名づけられている態度である。【[2019-04-29補足] 日本語でどういうのかわからなかったのだが、関野 樹さんによるHuTimeのサイトの暦変換サービスで「先発グレゴリオ暦」という表現が使われているので、これがよさそうだ。】さらに理想をいえば、月ごとの日数も、グレゴリオ暦にあわせる必然性はなく、むしろ均等割りのほうが合理的だ。

他方、人びとの記録を世界の地域間で対比するのが目的ならば、だれもグレゴリオ暦を使っていなかった時代にさかのぼってグレゴリオ暦を使うのはおかしい。自然科学者のあいだでも、こちらの態度のほうがもっともだと思った人が多いようで、CF Conventionの標準の暦は「gregorian」とされているのだが、これは1582年10月15日以後についてグレゴリオ暦を使い、それよりもまえはユリウス暦を使うようになっている。(その機能の実装は、udunitsというソフトウェアによっている。その仕様は Unidata Program Center (2014)の10節「The Handling of Time」にある。)

日本の古代中世地震史料研究会(2017)の「[古代・中世] 地震・噴火史料データベース (β版)」も、1582年まではユリウス暦、1583年以降はグレゴリオ暦を使うのを標準としている。これは、武者 金吉が編集した『増訂 大日本地震史料』(文部省 震災予防評議会, 1941)の「例言」に示された方針を引き継いだものである。ただし、実際の 増訂 大日本地震史料の内容の日付は「例言」に従っていないので、データベース作成者が修正して登録したそうだ。

グレゴリオ暦を、ローマ カトリック教会は、1582年10月15日から実施した。しかし、国によって、実施した年がずれている。プロテスタントの国ぐにでは18世紀になってから採用したところが多く、たとえばイギリスでは1752年からだ。(Wikipedia日本語版「グレゴリオ暦」の記事参照。)

(その結果、イギリスやアメリカ合衆国でつくられた暦の計算ソフトウェアのうちには、とくに対象地域をことわらないまま、1752年にきりかえているものもある。有名なものでは Unix の cal がそうだ。)

先近代の日本ではグレゴリオ暦もユリウス暦もほとんど使われていなかったので、日本の歴史資料を扱うシステムできりかえの時期をいつにするかは世界の対比の便宜上の標準という観点で決めればよいと思う。イギリスなど特定の国に合わせるよりも、1582/83年で変えるほうが妥当と思う。ただし、CF Conventionのように1582年10月15日からきりかえるか、地震・噴火史料データベースのように1583年初めからきりかえるか、という問題が残る。

- 2X -
ユリウス暦は紀元前45年初めから実施されたが、当初はまちがった運用やその修正があり、紀元後9年以降は意図された方式のとおり運用されている。(Wikipedia日本語版「ユリウス暦」の記事参照。)

CF Convention などは、紀元後9年以後のユリウス暦を、さかのぼって、ユリウス暦の制定前や、初期の不規則な運用の時期にも適用してしまう。古代ローマの歴史をあつかう場合にはそれでは不満が感じられるだろうが、世界の時間軸の便宜上の標準という意味では、「過去にさかのぼったユリウス暦」を使うと承知しておけば、それでよいだろうと思う。

- 3 -
日本の歴史資料をあつかううえでの「和暦」のおもな意義は、記録した人が実際に使っていた暦だということだ。ただし、実際に人びとが使っていた暦は不統一だったかもしれないが、その多様性までは対応しきれない。各時点での標準を採用し、もしそれと違う暦が使われていたのならば個別に記述するのがよいだろう。

日本の標準の暦を決めていたのは、律令制度のもとでは、陰陽寮だった。中国の「暦法」の計算方式(862-1684年は唐の宣明暦の方式)を採用して、中国の暦をそのまま使うのではなく、日本独自に計算した。貞享2年初(1685年2月4日)に実施された 貞享暦 以後は、幕府の天文方が決めるようになった。1873年(明治6年)にグレゴリオ暦が採用された以後の「旧暦」は、国定の標準はないが、国立天文台が近代的天文計算にもとづいて出す「暦要項」の「二十四節気、朔弦望」と、天保暦をひきついだ閏月の置きかたとによって決まる。(Wikipedia日本語版「太陰太陽暦」、「天保暦」などの記事参照。)

貞享暦以後は、暦法で決められたとおりの暦が発表され使われた。しかし、宣明暦が採用されていた期間には、陰陽寮の判断で、大小の月の入れかえなどで1日ずれたり、閏月を置く位置を変えることで1か月ずれたりする変更がされることがあった。暦法以外にも暦がもつべき特徴があってそちらを優先させるべきだと考えられたのだ。(Wikipedia日本語版「改暦」の記事の「宣明暦の「改暦」」の節 参照。)

たまたまグレゴリオ暦のはじまりと同じ年、1582/83年 (天正10/11年)に、日本国内の暦の大きな不統一があった。陰陽寮は宣明暦のアルゴリズムに従って天正11年閏1月を入れた。ところが民間の三島暦は、節気と閏月の関係の大原則に従って天正10年閏12月を入れた。織田信長が三島暦のほうを標準にするよう朝廷に要請したが、本能寺の変で未解決のままとなった。(上と同じWikipedia記事参照。)

貞享暦以後については暦法アルゴリズムで対応できそうだが、宣明暦の時代に実際に使われた暦を知るには、それにくわえて、陰陽寮による変更をひとつひとつ反映するパッチワークが必要になるだろう。どなたかがすでにアルゴリズムの形にしていれば、まねすればよいのだが。

- 4 -
ユリウス通日 (Julian Day) というものがある。これは、日を、年ごとにわけないで、とおしで数えるものだ。(Wikipedia日本語版「ユリウス通日」参照。)

ユリウス暦紀元前4713年1月1日の(現代の定義では、世界時の)正午を「元期」(時間軸の原点)、0日とする。連続変数としての時間を、日単位で、ただし整数未満の端数もつけた形で示す。

これは、Joseph Justus Scaliger (1540-1609)が1583年に提案したものだ。名まえは、提案者の父 Julius Caesar Scaliger (1484-1558)にちなんだものとも、ユリウス暦の制定者である Julius Caesarにちなんだものともいわれる。

これには、いろいろな変種がある。桁数が多くなるのを避けるために原点をずらしたもの、整数部分だけをとりあげたもの、などだ、変種のほうが単に「ユリウス日」「Julian Day」と呼ばれていることがあるので注意が必要だ。
【[2019-04-29補足] 気象の論文では「Julian Day」と書いてあったらたいていそれぞれの年の1月1日を1とした年内の通しの日付だ。気象むらの方言としては通用するのかもしれないが、わたしはすすめない。英語では「day-of-year」略して「DOY」と書かれていることもあり、そちらのほうがよいと思う。】
【[2021-02-06補足] 計算機利用の関係では、1970年1月1日0時を原点とする「Unix 時間」というものがあるが、これを日単位にした、1970年1月1日からの日数を「Julian Day」と言っているのを見かけた。わたしはまだ、これがどのようなひろがりでつかわれているのか、つかんでいない。】

情報共同利用システム内部の日付情報のもちかたは、西暦よりも、このような通しの日付のようがよいかもしれない。それにしても、本来のユリウス通日にするか、いずれかの変種にするか、という問題が残る。

- 5 -
日付だけがあるデータと、日付と時刻のあるデータとがまざったとき、時間軸上で日付・時刻をどうあつかうか、という問題がある。

歴史記録の場合は、日付だけの場合が多く、時刻情報があるとしても精密ではないから、日付と日のうちの時刻とを別の項目として扱ったほうがよいかもしれない。

その場合でも、1日の切れめをいつとするかという問題はあるだろう。現代日本の公式な記録では、日本標準時の正子(深夜の0時)でわけている。歴史記録の場合も、日本の場合は大まかにそれと同じと想定してよいだろうと思う。(ユダヤ教のように1日が夕方から始まるという伝統がある場合には別のやりかたが必要になるかもしれない。)

他方、日付と時刻をあわせてひとつの時間軸座標としてあつかう必要があるかもしれない。計算機ソフトウェアで、日付と時刻があるのが原則であるところに日付だけのデータがまざったとき、時刻を 0 として処理するものが多いようだ。そうすると、1日の情報に、その日の初めの時刻をあてることになり、時間軸上の位置が一方にずれる。ずらさないように、その日のまんなかの時刻、つまり(日の切れめが正子だとすれば)正午にしたほうがよいという考えもある。また、時間軸上の区間をあつかう場合は、たとえば「9月1日--2日」は「9月1日00:00--9月2日23:59」のようにみなすべきという考えもありうる。

切れめの時刻をどちらの日に入れるかという問題もある。切れめが0時だとすれば、新しい日の0時なのか、古い日の24時なのかという問題だ。これで迷うことは、歴史記録についてはあまりおこらず、近代の観測値についておこりやすいだろう。気象データの場合、気温など、概念として瞬間の値は、0時の値とする。しかし、降水量など、累積の値では、「24時までの降水量をその日の降水量とする」というあつかいをすることもある。そのような習慣が、データの提供者と利用者のあいだでくいちがうおそれがある。それに気づかないと、できごとを時間軸上で1日ずれて解釈してしまうおそれがある。

- 6 (余談) -
日付のきれめの時刻が変更されると、変更のところでトラブルがありうる。

これについて思いあたる事例があるのでふれておく。ただし、この事例には夏時間がからんでいる。夏時間の実施は 1916年(ドイツ、イギリス)以後であり、それが前提とする標準時の制度も1884年の国際子午線会議のころに確立したものなので、それよりも古い歴史記録のあつかいでは、直接これと同じ種類の問題はおこらないだろう。

奥村 晴彦さんが、2018年7月16日のtweetで、最近の経験について述べていた。毎日の気象データについて計算機で統計処理をしようとしたら、1948年5月2日のところでエラーになって処理が止まった。その原因は次のようなものだったとわかった。

  • 奥村さんが使った計算機のOS (オペレーティングシステム)には、time zone ライブラリがあり、現在地のtime zoneは(おそらく「Asia/Tokyo」のような形で)日本に設定されていた。
  • 1948年から1951年までの夏は、日本は夏時間を採用していて、時刻を1時間ずらしていた。1948年の夏時間開始は5月2日で、5月1日23:59の1分後が5月2日01:00になっていた。その知識はOSのtime zoneライブラリに含まれていた。
  • 入力データは1日1回の情報だったので、時刻のフィールドはなかった。奥村さんが使ったプログラムは、時刻として0をおぎない、time zone ライブラリを使って、時間軸の座標値を計算しようとした。ところが Asia/Tokyo の1948年5月2日00:00という時刻は存在しないので、エラーになった。

実際には、日本の気象庁の気象データは、夏時間を使わず、ずっと標準時で記録されていた。だから、time zone を一貫して日本標準時(JST)つまり世界時より9時間進んだ時刻(UTC+09)として処理すればよかったのだ。ただし、そのような time zone を使うように、OS や言語処理系ごとの約束ごとを知って、指示しなければならない。

(また、この事例にかぎっては、time zoneはAsia/Tokyoのままでも、時刻としてたとえば 12:00 をおぎなって処理すれば、エラーをおこさずに計算することはできた。)

この事例を離れて言えば、夏時間のきりかえの時刻は、日のさかいめと同時とは限らない。人間社会の活動がすくない時間をえらんで、たとえば午前3時にすることもあるらしい。また、近ごろは、ヨーロッパ、北アメリカ、それぞれの大地域内では、世界時で同時に切りかえるので、地方標準時で同じ時刻とはかぎらない。

文献