Apps Developer AStIS

[余談:時憲暦の置閏法]Digression

時憲暦の置閏法はすごく単純で明快です。

①冬至を含む月を特別中気とみなし、11月を割り当てる。
②11月から翌11月までの間が12ヶ月の場合(12月、1月…9月、10月)は、冬至間の最初に発生する中気を含まない月を閏月とする。

システムを組んだことがある人間としては、どうしても時憲暦の置閏法に美しさを感じてしまいます。
個人的には、日本人としての矜持を捨て、過去の日本人に習い、良いものは何でも採用すべく、
時憲暦を太陰太陽暦の最終決定版にすべきであると思っています。

しかし、敢えて天保暦の良さを挙げるとすれば、以下の通りです。

①時憲暦では冬至間の1年のスパンで月を決めるが、天保暦では二至二分という3ヶ月間のスパンで月を決める為、
 より季節にフィットした月の割り当てができる。
②ロジックで暦を作成する際、時憲暦では必ず冬至間の月数(最大で14ヶ月分)を算出する必要があるが、
 天保暦では二至二分間の月数(最大で5ヶ月分)の算出で済むため、処理時間が少なくて済む。

①に関しては、実際に天保暦と時憲暦で作られる暦を比べると、大多数の年で差がありません。
例えば、天保暦ルールが破綻しない年月で時憲暦で違いが出てくる年月は1851年等、非常に少なく、
季節云々の話はあまり意味がありません。あくまでルールによって追及している理念的な差に過ぎず、
実用的に考えても時憲暦のルールで困るとは考えられません。
(ひょっとしたら時憲暦側もそこまでシミュレートした結果、あえて、冬至のみを基準にしたのかもしれないですが。)

②に関してはロジックで暦を作成せず、「現行暦で旧暦はこの年月日」と予め換算しておいた結果を使用するのであれば、
まったく問題になりません。また、仮にロジックで暦を作成するにしても処理能力の高いデバイスであればあるほど、
その差は縮小してしまいます。
そして何よりもルールが破綻してしまうことがあるという時点で天保暦は時憲暦にかないません。

ここまで、自身でさんざん時憲暦を持ち上げておきながら、天保暦を擁護するのはおこがましいですが、
①の二至二分で月を割り当てる方法は、季節へのフィット以外にも、わざわざ冬至まで遡らなくても良いことを意味します。
(秋分から冬至までの間の期間の場合、わざわざ前年の冬至まで遡る必要があるかないかの差があります。)

それは、天保暦や時憲暦が成立した時代では、わりと利便性が高くなる効果があるのではないでしょうか。
そろばんがあるとは言え、コンピュータがあるわけではないので、計算量が減ると言うことは、正確性を高くすることに
寄与するのかもしれません。更に①の計算上の利点はそのまま②の利点に直結します。

また天保暦が成立した当時、現代のような天文的な観測精度がありませんし、
ましてや、コンピュータで高速で大量に計算することもできません。
約200年先までの暦をチェックし、矛盾がないか確認せよと言うのはあまりにも酷ではないでしょうか。
ましてや成立後、すぐに1851年の様な成功例もあるので、なおさら天保暦には矛盾がないと信じてしまうでしょう。

ちなみに下記が1851年の天保暦と時憲暦です。(どちらも標準時はUTC+9です。)

天保暦:1851/11・時憲暦:1851/11:1851/11/23~1851/12/22:小雪(1851/11/23)、冬至(1851/12/22)
天保暦:1851/12・時憲暦:1851/閏11:1851/12/23~1852/01/20:中気なし
天保暦:1852/01・時憲暦:1851/12:1852/01/21~1852/02/19:大寒(1852/01/21)、雨水(1852/02/19)
天保暦:1852/02・時憲暦:1852/01:1852/02/20~1852/03/20:春分(1852/03/20)
天保暦:1852/閏02・時憲暦:1852/02:1852/03/21~1852/04/18:中気なし
天保暦:1852/03・時憲暦:1852/03:1852/04/19~1852/05/18:穀雨(1852/04/20)
天保暦:1852/04・時憲暦:1852/04:1852/05/19~1852/06/17:小満(1852/05/21)
天保暦:1852/05・時憲暦:1852/05:1852/06/18~1852/07/16:夏至(1852/06/21)

そもそも、天文的なデータに基づく暦に破綻がない暦は存在しません。
天文学的な時間ベースでみれば、太陽や月、地球等の運行は変わってしまうので、完璧な暦など存在しないのです。
総合的に考えて、時憲暦も天保暦も当時の英知が結集された稀代の太陰太陽暦なのです。