qreki

qreki

[1] qrekiグレゴリオ暦から旧暦に変換できるプログラムです。 からの間の日付を正しく扱えます。

[2] オリジナルは AWK スクリプトですが、色々な言語に移植されて広く使われています (>>6)。

[40] 後述の通り、もはや本ソフトウェアを使用するべきではありません。

[19] 旧暦一般や他の旧暦変換表等との比較については、旧暦を参照してください。

オリジナル版

[3] このスクリプトは先発グレゴリオ暦 (0年あり) を入力とし、 旧暦六曜を出力としています。

[5] ただしこのスクリプトは自由ソフトウェアではありませんから、注意が必要です。

[4] qreki のドキュメントには旧暦についての詳細な解説が含まれています。 >>8 からダウンロードできるファイルに含まれているほか、 >>27 にも転載されています。

移植版

[6] 次の移植版が知られています。

[38] Yahoo!カレンダー元号表示、旧暦六曜に対応しているのですが、 21世紀を扱えない qreki の不正確さがそのまま反映されていて残念な感じです。

正確性

[18] からの間の日付については、 正しい結果を返すことが知られています。それ以外の期間については、 誤った結果を返す場合があります。

[33] 既に正しい結果を返せる期間を過ぎている以上、メンテナンスされていない本ソフトウェアを使うべきではありません。 移植版も正しく動作しない可能性が高く要注意です。

[23] オリジナル版には原理の説明も入っているのですが、 移植版は十分に説明していないことがあり、利用者に誤解を与える危険性があって要注意です。

[26] 過去の日時については、実際の旧暦は時代により計算法が異なっていたところ、 本ソフトウェアは (意図的に) 天保暦ベースの計算法にのみ対応しているため、 歴史的に正しい結果を得ることができません。従って、本ソフトウェアを歴史上の出来事に関する暦の換算に用いることはできません。 旧暦

[25] 将来の日時については、そもそも原理的に不確定なものであり、 本ソフトウェアが作成されたの時点よりも後の時代の日時を完全に予測できませんから、 正しい値を返さないとしても、必ずしも不具合というべきものではありません。 (かといってそれが有用かどうかはまた別の問題ですが。)

[30] 旧暦2033年問題を正しく扱えません。本ソフトウェアが作成された時点では対策が確定していなかった (問題も広く知られていなかった) のですから、無理も無いことです。 旧暦2033年問題

[29] について正しく扱えないことがドキュメントにも明記されています >>28 が、これも旧暦2033年問題同様の問題であることが後に知られています。 旧暦

[31] 21世紀中では他にを正しく扱えません。 これらはに出版された21世紀暦で、 自転速度や誤差が原因で異なる日付になる可能性があると指摘されているもので (21世紀暦は他にも指摘しているが、これは qreki も正しい)qreki 以外のソフトウェアも異なる結果を返す場合があります。 (旧暦 (>>24)) 参照。

[32] ただし、ここでは21世紀暦が主たる表で採用しているものを正しいとしていますが、 未到来の日付qreki の結果が正しい可能性も残っています。

[28] >>27

2224年 3月21日から、同年 4月18 日の期間(グレゴリオ暦法による日付)の月名が間違って表示する現象が確 認されています。 具体的には、 正しい答えが3月であるのに対して、 閏2 月と表示する現象です。中気の計算に問題があると判明していますが、 今の 所、良い対策方法が見つかりませんので、そのままにしてあります。

[151] 旧暦を取得する Web API ( 版) http://api.sekido.info/qreki?output=usage

本スクリプトの計算精度については、暦計算研究会編の「新こよみ便利帳」に記載の新旧対照表で、2000年から2020年までを確認したところ、2017年2月26日~同3月27日までが、旧暦・六曜表示に誤差のあることが確認されています。

旧暦計算ライブラリ(Perlによる旧暦計算プログラム) http://www3.biwako.ne.jp/~nobuaki/qreki/index.html
[24] QReki.javaの不具合 - Qiita (2017年03月13日に更新 ) https://qiita.com/yamori813/items/b4d2d3d34e25654ecbe6

日本時間の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スクリプトはいろいろな言語に移植されているようですが、他でも問題が起きている可能性があるかと思われます。

根本的に直すのは難しいのでアプリには2017/2/26から3/27までのworkaroundを入れました。