QReki.javaというオープンソースを自分用の暦アプリで使っているのですが、旧暦の表示がずれていたので、確認してみました。
旭川情報ねっとさんの暦のページをみると3月5日は旧暦2月8日となっています。
旧暦は新月すなわち朔が1日となります。今年に入ってからは1/28が始めての朔だったので、1/28日が旧暦の1/1になりました。
朔の正式な日時は、国立天文台が毎年公表している下記のデーターが元になります。
QReki.javaはこの朔を計算して旧暦を返してくれます。
| 朔日時 | ユリウス日 | QReki.java計算値 |
|---|---|---|
| 2016年11月29日 21時18分 | 2457722.01250 | 2457722.014176843 |
| 2016年12月29日 15時53分 | 2457751.78681 | 2457751.788357215 |
| 2017年1月28日 9時07分 | 2457781.50486 | 2457781.506297572 |
| 2017年2月26日 23時58分 | 2457811.12361 | 2457811.125400158 |
| 2017年3月28日 11時57分 | 2457840.62292 | 2457840.624657503 |
日本時間の2/26はユリウス日の2457810.125から2457811.124となります。ところがQReki.javaの計算値は2457811.125400158となり次の日になってしまっているので旧暦の2/1が2/27になってしまっています。
日をまたぐ0.125日前後に新月になるとこのように誤差でずれてしまう事がありあります。計算で出すには1分は0.000694日なので小数点以下3-4桁くらいの精度が必要と思われます。
そもそもQReki.javaのユリウス日の扱いはちょっとおかしい気がします。上記の数値はちょっといじって出しています。
QReki.javaはawkスクリプトからの移植で、このawkスクリプトはいろいろな言語に移植されているようですが、他でも問題が起きている可能性があるかと思われます。
計算で出す方法は誤差が発生しこれにより違った暦が出来てしまうので、国立天文台で暦要項のWebAPIを提供してもらえると良いのではないかと思います。
根本的に直すのは難しいのでアプリには2017/2/26から3/27までのworkaroundを入れました。
この問題は旭川情報ねっとさんの暦のページで概要を知り調査しました。旭川情報ねっとさんの情報が大変参考になりました。ありがとうございました。
旧暦は2033年問題というのもあるようです。