[1] qreki はグレゴリオ暦から旧暦に変換できるプログラムです。 西暦1948年から西暦2016年の間の日付を正しく扱えます。
[2] オリジナルは AWK スクリプトですが、 様々なプログラミング言語に移植されて広く使われています (>>6)。
[40] 後述の通り、もはや本ソフトウェアを使用するべきではありません。
[65] qreki およびその派生ソフトウェアの正確性には問題があります。
[18] 西暦1948年から西暦2016年の間の日付については、 正しい結果を返すことが知られています。それ以外の期間については、 誤った結果を返す場合があります。
[33] 既に正しい結果を返せる期間を過ぎている以上、メンテナンスされていない本ソフトウェアを使うべきではありません。 移植版も正しく動作しない可能性が高く要注意です。
[23] オリジナル版には原理の説明も入っているのですが、 移植版は十分に説明していないことがあり、利用者に誤解を与える危険性があって要注意です。
[26]
過去の日時については、実際の旧暦は時代により計算法が異なっていたところ、
本ソフトウェアは現代日本用の計算法を実装しているため、
歴史的に正しい結果を得ることができません。従って、本ソフトウェアを歴史上の出来事に関する暦の換算に用いることはできません。
[25] 将来の日時については、そもそも原理的に不確定なものであり、 本ソフトウェアが作成された西暦1994年の時点よりも後の時代の日時を完全に予測できませんから、 正しい値を返さないとしても、必ずしも不具合というべきものではありません。 (かといってそれが有用かどうかはまた別の問題ですが。)
[30]
本ソフトウェアは旧暦2033年問題を正しく扱えません。
本ソフトウェアが作成された時点では対策が確定していなかった
(問題も広く知られていなかった)
のですから、無理も無いことです。
[29]
本ソフトウェアが西暦2224年について正しく扱えないことがドキュメントにも明記されています
>>28。
これも旧暦2033年問題同様の問題であることが後に知られています。
[31] 本ソフトウェアは21世紀中だけでも他に西暦2017年
(旧暦2017年問題)、
西暦2051年、
西暦2074年を正しく扱えません。
これらは西暦2000年に出版された21世紀暦で、
自転速度や誤差が原因で異なる日付になる可能性があると指摘されているもので
(21世紀暦は他に西暦2096年も指摘しているが、これは qreki も正しい)、
qreki 以外のソフトウェアも異なる結果を返す場合があります。
[359] 他に、 、 、 にも問題が指摘されています。
[360] 派生ソフトウェアの中にはこれらのいくつかを修正したものもありますが、 すべてを修正したものは確認されていません。 (すべてを修正したらもはや別物になってしまいそうです。)
[398] 派生版は独自の不具合を生じている可能性も否定はできません。 派生版の品質の検査を行ったと明記していないものも多いです。 注意が必要です。
[66] 不正確なソフトウェアの普及による被害は、 西暦2017年問題を参照。
本スクリプトの計算精度については、暦計算研究会編の「新こよみ便利帳」に記載の新旧対照表で、2000年から2020年までを確認したところ、2017年2月26日~同3月27日までが、旧暦・六曜表示に誤差のあることが確認されています。
日本時間の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を入れました。
[106] 本ソフトウェアが誤った結果を生成することは、 オリジナル版制作当時に出来たことの限界もありますから、 あまりその責任を追求しすぎるのも適切ではありません。 しかしその社会的影響の大きさを考えると、 誤りがどのように発生し、見過ごされてきたかは検討されるべきで、 今後の教訓とされるべきといえます。
[100] ドキュメントによると、当ソフトウェアオリジナル版はその公開にあたって
... を検査し、西暦2224年問題 (>>28) を除き問題がないと確認した >>70 とされています。
[104] これを読むと十分な正しさが保証されているように感じられます。 ところがに JavaScript 移植版の作者が、 、 西暦2017年問題、 西暦2033年問題を発見しています (>>93)。 には PHP 移植版のうちの1つの利用者がとの問題も発見しています (>>263)。 なぜオリジナル版でこれらの問題が検出されなかったのでしょうか。 (できれば当時の AWK 版の実行環境を再現して検証したいところですね。)
[105] >>101 は 暦の百科事典 を規範としているのですが、 >>103 は 「結果が正しく表示されている」 ことしか検査していません。 適当な正解データが得られなかったために西暦2017年問題等は見落とされたのでしょうか。 西暦2224年問題を検出しながら、西暦2033年問題を検出できなかったのはなぜでしょう。
[107] オリジナル版制作のきっかけとなった >>70 TODAY というソフトウェアは、 JavaScript 移植版の作者が検証に使ったものなのですよね (正確に言えば両者はバージョンが違い、その間に大きな変更が加わっているのですが)。 オリジナル版は TODAY を検証に使わなかったのだろうかという疑問もあります。
[69]
オリジナルは日本語 (シフトJIS) 化された
MS-DOS
版 gawk 用の AWK スクリプトで、
高野英明により開発されました
>>70。
[71] 現在も付けで配布 >>8 されているものはドキュメントに 「Rev 1.1」 と書かれており、 著作権表示がとになっているものです。 >>70
[3] このスクリプトは先発グレゴリオ暦 (0年あり) を入力とし、 旧暦と六曜を出力としています。
[5] ただしこのスクリプトは自由ソフトウェアではありませんから、注意が必要です。
[4] qreki のドキュメントには旧暦についての詳細な解説が含まれています。 >>8 からダウンロードできるファイルに含まれているほか、 >>27, >>70 にも転載されています。
[73] 「Rev 1.1」になる前の元のバージョン (1.0) はに作成されたと推測されますが、 入手不能です。当時は NIFY-Serve や ASAHI-NET で配布されていたと思われます。
[108] 製作に当たり当時出版されていた暦関係の書籍が一通り参照されたようです。 その他、 先行していたソフトウェアとして
... が参照されていました。 >>70
[72] オリジナル版の「Rev 1.1」からの直接または間接の移植と思われます。 (オリジナル版に基づかず孫以下の世代のものもあります。)
S61 * 暦の百科事典 1986 : S62 : 1987 : S63 : 六曜プログラム * 1988 : : 1/ >>110 S64/H1: : 1989 : H3 : 新こよみ便利帳 * 1991 : : H4 : : : 1992 : :TODAY >>109 : : H5 : : QRSAMP : : 1993 : :.........................>o.........................: : : : | >>73 : : H6 : : | : 1994 :....:.........................>* Rev 1.1 : : : | 10/2 >>71 : : | : : (表) | : H11 : : qreki.js | : 1999 : :.....>o<--------------+ Web : : : : | 11/8 >>95 | Calendar2 : : :..>o<.....| 11/8 >>95 | o 11/10 : :...:.....>| | :>>84 : : :11/16 | | : : : : >>97 | | : : | | :qreki.pl: H12 | +---------------------->o* 6/9 : 2000 |...............|......................>||>>123 : 7/15 o<-+ | || : >>295 |<.|...............| | : 10/12 o | | |......: >>294 | | | | : H13 1/8 o o | | 2001 >>289 | | | qreki.pl | 4/6 o o 1.3 | >>15 o | >>288 | | 4/18 >>86 | | | | o 1.31 | | | | | 4/21 >>86 | | | | o 1.4 | | | | | 6/3 >>86 | | | 11/15 * * 1.5 | | | >>287 | | 10/4 >>86 | | | | |旧暦 for VB | | | H14 | +--->*<---------+ | | 2002 | | | 5/27 | | | | | |>>11 |qreki.php | H15 | | | |2/ *<-------------------+ 2003 | | | |>>9| Qreki | | | | |..>| 4/10 >>162 *<------+ | | | | | mt-kyureki.pl | | | | | | 9/20 >>179 *<-+ | | | |...|................>| | | | | | | | | | | | | | | H16 3/11 * | | | |統一カレンダー | | 2004 >>286 | | | | +->o 0.09 >>354 | | | | | |...|.>| 12/28 <.......|.| | |....|..........|...|.>o 0.91 | | | | | | | | 12/31 | | H17 | | | | | o 0.92 | | 2005 | | | | | | 1/8 | | | | | | | o 0.93 | | | | | | | | 1/16 | | | | | | | * 0.94 | | | | | | | | 1/17 | | | | | | | o 0.94 | | | | | | | | 1/18 | | | | | : | o 0.94-1 | | | | | :なでしこ | | 1/21 | | | | : | * 0.94-2 | | | | 4/27 *<-----+ | | 1/28 | | | | * 5/1 | | | | | | | |>>511 | | | | | | | >>465 | | | | | | | | o 7/ | | | | | | | | Rokuyou | | | :nencal | | | | | 8/13 *<-| | :>>476 exdate | | | | | >>202 | | |>>220: >>132 o<-+ | | | | | | | *..: | | | | | | | | | | | : || | | | | | | | |...|.|..............>|| | H18 | | | | | | | | | 1.03 *| | 2006 | | | | | | | | | 3/17 >>408 || | | | | | | | |qreki.php || | | | |qreki.php | |...|.|..>o<----------||-+ | | |wp-koyomi | | | | | 3/25 >>256|| | | +-->* 10/14 | | | | o 9/9 || | | | | * 10/15 | | | | | >>260 || | | | | |>>266 <.|..| | | || | | | | |<.......| | | | || | | | | | | | | || | H19 1/31 *<--+ | | | | | | | || | 2007 >>238 | | | | : | | | || | | | | | 携帯潮汐: | | || | H20 | | | | : | |Web API || | 相互変換 2008 | | | | |3/14 *:<--+ +--->* 4/1 || | 1/5 * | | | | |>>56 `+ |...|...>| >>310 || | >>193: | | | | | 6/3 o | | | || | : | | | | | >>485| | | | | || | : | | | | | 6/26 o | | | | || | : | | | | | >>485| | | | | || | : | | | | | | | | | | || | : H21 | | | |旧暦六曜,+ | | | | || | : 2009 | | | | 4/1 o| | | 0.4.2 | || | : | | | | | >>59|| | | qreki_py<..| | | : | | | | | | +---|-->o<.......|.....| | : | | | |..|...|.|....|...|..>| 11/28 | | | : | | | | | | |....|...|..>|>>12 | || | : | | | | | | | | | o 11/ | | | : | | | | | | | | | | * 12/1 | | | : | | | | | | | | | | | 0.4.6 | | | : H22 | | | | | | | | | +,|ゴミ箱 | | | : 2010 | | | | | | | | | |*|1/10 | | | : | | | | | | | | |*|1/11 | | | : | | | | | | |SAORI | ||>>442 | | : H23 | | | | | | +->* 2/21| | 1.04 * | : 2011 | | | | | | | |>>552| | 9/1 >>407 | | : | | | | | | | | | | | | : H24 | | | | | | | | | | 1.05 * | : 2012 | | | | | | | | | | 1/31 >>406 | | : | | | | | | | | | | | | H25 | | | | | | | | | | | | | Date::Qreki 2013 | | | | | | | +->* 0.01 | | | | | | DQRSAMP.AWK | | | 3/9 >>208 | | | | | +->* 9/15 >>629 | | | | | | | | Gem |... ............|.......|.>| : | | | | | 11/14 *<-+ +->* 11/29 | | | : | | | | | >>150| | | | >>16 | | | : | | | | | 12/5 * | | | | | : | | | | | >>150| | | | | | | H26 | | | | | | | | | | * 0.02 2014 | | | | | | | | | | | | | 2/7 >>208 | | | | | | | | | | | | * 0.03 | | | | | | | | | | | | | 2/11 >>208 | | | | | | | | | | | | * 0.04 | | | | | | | | | | | | | 2/11 >>208 | | | | | | | | | | | | * 0.05 | | | |旧暦六曜| | | 2/12 >>208 カレンダー | 6/13 * | | | | | 9/2 *<--------+ >>150| | | 11/6 o | | : |>>327 | | |暦API | >>149| | | : H27 | | | | o | | | | : 2015 | | | | | | | | |>>170| | | | | | | | | | | | | go-qreki H28 | | | | | | | | mk- >>128 o<-+ | 3/ * 2016 | | | | | | | |calendar 2/5 | | | >>493: | | | | | | +------ | --->* | | : | | | | | | | | |>>580 | | : | | | | | | | | | 6/ | | : | | | | | | | | * 7/ | | : | | | | | | | | * 9/ | | : | | | | | | | | | | | : | | | | | | | | | | | : H29 | | | | | | | | | * 0.06 2017 | | | | | | | | | | 1/31 >>208 | | | | | | | | | * 0.07 | | | | | | | | | 1/31 >>208 | | | | B | A | C版 | | | | | | | 3/8 **<--|-------|---- | ------------|----+ : | | | | >>187|: +>*8/25 |>>48 | | : : | | | | | |>>57 *10/ | | : : | | | | | | | *11/12| | : : | | | | | | *12/ | | : : | | | | | | | | : : | | | |JapaneseDate |Scheme | | | : : H30 | | | * 5/19 | o3/31 | | : 2018 | | | |>>22 | | |>>39 | | : | | | | | | | | *11/4 : | | | | | | | | | : | | | | | | | | | : H31/R1 | | | * 7/9 | | | | : 2019 | | | * 10/5 | | | | : | | | | | | | | : R2 | | | * 3/ | | | | : 2020 | | | * 12/19| | | | : | | | |>>21 | | | | : R3 | | | | | | * 5/25 : 2021 | +- | | ->*3/ | | | : | | | | |>>602 | | : | | | | | | : | | | | | | : | >>432| | |>>518 | | Qreki : |*<----+ * 7/10 +-------|-->* 8/23 : ||<....|........|......| | * 8/22 : |<.....|........|......| | |>>487 : |>>234 | | | |..>| : || | | | | | Qreki_nako : R4 || | |......|.......|...|..............>* 1/17 : 2022 || | * 2/8 | | | :>>527 : || | | |>>517 | | | qreki.go : || +--+--------|------|-------+---|------>*.............: || | | | | | | | 4/ 5/ : | >>490
[574] 凡例:
[88]
多くの派生版がオリジナル版と共に参照しているのが、
長野隆が
Webブラウザー / WSH 向け
JavaScript
に移植した
qreki.js。
[95] 自身のWebサイトの六曜表示に従来は一覧表を用いていたところ、 に翌年のデータがないことに気づき、 qreki を移植して利用することにしました。 >>87
[96] qreki は当時の主要なポータルサイトの1つ Infoseek で発見したのだといいます。 他の実装は一覧表形式で、 qreki は計算方式だったのが採用理由と説明されています。 >>87 一覧表の継続的なメンテナンスを嫌っての判断だったのでしょう。
[97] ところがに当時人気だったカレンダーソフトウェアの1つ TODAY との比較で qreki の旧暦計算の誤りに気づきました。 そのため六曜表示は qreki ではなく、 従来通りの一覧表形式に戻すことにしました。 >>93 qreki の西暦2017年問題や西暦2033年問題もこの時既に発覚していました。
[98]
にも関わらず、 qreki.js はその後も
(旧暦日付計算に関係しない)
改良が加えられて配布され続けていました。
旧暦日付の誤りについては、
リンクをたどれば到達できるものの、
配布ページでは何の注意もされていませんでした。
>>86
1999年11月8日(月)
このページ上部に「大安」「仏滅」などの六曜表示がついていますが、これはあらかじめ調べた六曜表をもとにテーブル参照をするJavaScriptを作成して表示しています。この表が今年の年末までしか用意されていないので、来年以降、六曜表示ができません。
そこで、
Infoseek リンク を使って旧暦を計算するアルゴリズムを検索したところ、そのほとんどがテーブル参照方式であった中に、「旧暦計算サンプルスクリプト/H.Takano(C)1993,1994 リンク先: >>8 」という、きちんと計算して求める方式のものを見つけました。MS-DOS上のjgawkで書かれたスクリプトで、詳しいドキュメントが付いています。そのAWKで書かれたプログラムを、Webブラウザで動作するようにECMAScript(
ECMA-262 リンク )で書き直したのが、「qreki.js リンク 」です。ECMA-262準拠のJavaScriptを搭載する、Netscape Navigator 3.01以降、Microsoft Internet Explorer 4.0以降(MSIE 3.0xの方はScript Engines 5.0をMicrosoftのサポートページ リンク からダウンロードしてインストールすることで動作します)で動作します。ECMA-262に準拠していないJavaScript対応ブラウザをご使用の場合はエラーが出ます。面倒なのでバージョンチェックは省略しています。我慢してください。 赤字 こちらでは、MSIE5.0-Win98 と Netscape Navigator 4.61-linux-glibc で動作を確認済みです。
1999年11月16日(火)
先週この欄にて公開 リンク先: >>87 した「旧暦計算スクリプト」ですが、テーブル参照型の暦計算プログラムの金字塔である「Today ソースコード リンク 」(森佳史さん リンク 作)の中の旧暦西暦換算表 "kyutbl.c" と照合してみました。西暦 1870年2月1日 ~ 2100年3月11日 の間で旧暦の毎月1日の日付を照合したところ、以下の点で私のスクリプトは「Today」と違った結果を出していました。旧暦 西暦(誤) 西暦(正) 誤差を含む期間(西暦) ----------------------------------------------------------- 1884/4/1 1884/4/25 1884/4/26 1884/4/25 - 1884/5/24 1908/9/1 1908/9/26 1908/9/25 1908/9/25 - 1908/10/24 2017/2/1 2017/2/27 2017/2/26 2017/2/26 - 2017/3/27 2033/11/1 (月名を閏11と間違える) 2033/12/22 - 2034/1/19このページの上部に表示している六曜は換算表をもとに出力していることは先週書きましたが(このページのHTMLソースを見れば一目瞭然)、ECMAScript版の「旧暦計算スクリプト」は動作環境に制限があるので、それを使って来年の分の換算表を作成して今まで通りに六曜を表示させることにしました。
2001年4月21日(土)
JavaScript旧暦計算ライブラリ リンク Version 1.3 にはバグがありました。月齢を計算する部分で早トチリして誤った計算をしていました。修正版の Version 1.31 を配布していますので、そちらをご使用ください。2001年4月18日(水)
JavaScript旧暦計算ライブラリ リンク に、月齢を計算するメソッド(というかプロパティ)を追加しました。月と太陽の黄経の経度差が1朔望月(≒29.53089日)で1回転するという前提で:月齢[day] ≒ norm( 月黄経[degree] - 太陽黄経[degree] ) ÷ 360 × 29.53089
という式で計算しています。norm() は、角度を0-360の間に正規化する関数です。詳しくは、
ライブラリのソースコード リンク をご覧下さい。このソースコードの拡張子を「.js」に変更して保存すると、HTMLやWSHなどから呼び出すことができます。
このスクリプトは、高野英明氏による「旧暦計算サンプルスクリプト/H.Takano(C)1993,1994」を私がJavaScriptに移植したものです。
Version 1.5 [Oct.4,2001] 月相を追加。
Version 1.4 [Jun.3,2001] 月齢を定義通りに計算するよう修正。輝面比を追加。
Version 1.31 [Apr.21,2001] 月齢計算のバグ修正。
Version 1.3 [Apr.18,2001] 月齢近似値計算機能を追加。
©1999-2001; by Nagano Yutaka
[295] には既に他の人が利用して公開していたことを確認できます (ソースコードコメントによれば更に遡って)。 >>294 そのまま使うだけではなく機能追加版も作られ、 他の言語にも移植されました。
qreki.js は AWK 版を参照しつつ >>88 から派生。| 10月 | 22 | 今日のこよみ | 旧暦、六曜、西暦年の元号/十干/十二支、和月名、祝祭日、二十四節気、月齢から潮汐、月名、月齢画像などを表示する今日のこよみ-JavaScript登録。 |
404、それ以前の所蔵なし。qreki.js を頃更に修正して利用している。[旧暦及び六曜、及び月名に関する誤りについて]
当サイトで採用しております旧暦計算スクリプトにおいて、2017年2月26日から同3月27日の間の旧暦表示及びそれに伴う六曜の表示、月名の表示に誤差が発生することが判明しましたので、当該期間(旧暦2017年2月分に該当する期間)のそれら項目について利用されないようお願いします。
当サイトのスクリプトでは旧暦2017年2月の朔を新暦の2月27日としていますが、国立天文台の見解では2月26日23:58となり新暦26日を朔日(旧暦の1日)とすることになった為です。
- 和暦(元号)表示は明治以降のみ表示されます。
- 祝日の表示は1873年(明治6年)10月14日太政官布告「年中祭日祝日ノ休暇日ヲ定ム」とその後の変更、1912年(大正元年)9月4日公布「休日ニ関スル件」とその後の変更、1948年(昭和23年)7月20日公布の「国民の祝日に関する法律」とその後の改正によります。又、皇室慶弔行事やその他の国事行事に伴う特別な休日の扱いを定めた個別の法律を反映しました。 月齢欄の「上弦の月、満月、下弦の月」の表示は2000年から2030年の間のみ対応しています。
- 2017年2月26日から同3月27日の間(旧暦2017年2月分に該当する期間)の旧暦変換に誤差が有りその間の旧暦表示及び六曜の表示、月名の表示は利用できません。2月26日を朔日として旧暦2月1日・友引とし3月27日を月隠、旧暦2月30日・先勝とし、その間旧暦表示を1日早める形で読み替えてください。
旧暦表示については西暦1870年から2074年までの表示についてサンプリングにて確認していますが全ての確認は仕切れていません。
2017年問題 リンク: 日経 、2033年問題 リンク: 国立天文台 及びスクリプトqrekiに関し指摘されているその他問題点は解決したつもりです。
[542] 別系統のものもあります。
六曜の取得について検索しているとこちらの記事がヒットし、大変ためになりました。
こちらのソースの改変・二次利用についてなどライセンスはありますか?ぜひ使わせていただきたいです
ここは、タイトル通り私のゴミ箱です。捨てて置いたのですからお好きにどうぞ。
もしあなたがこのコードでボロ儲けしたのなら、おすそ分けを…。^^;
[123] までに N.Ueno が公開した Perl 移植版も広く利用・参照されました。 当時はCGIの最盛期で、CGIスクリプトの記述言語として最も人気があったのが Perl でした。
[126] qreki の JavaScript 版を参照しつつ、 元の AWK 版から移植されました。 >>81
[125] N.Ueno は自作のカレンダー Webアプリケーション (Perl で書かれたCGIスクリプト) Web Calendar2 の六曜表示機能を、 従来の表方式のものから計算方式に置き換えるため、 qreki を移植したのだそうです。 >>81
[124] Perl スクリプト単体でも Web Calendar2 としてもよく使われていたようで、 Web Calendar2 が設置され稼働中のサイトが現在も数件見つけられます。
[127] 製作者はからの範囲の計算結果を 新こよみ便利帳 と比較し、 西暦2017年問題を検出したことを書いています >>81。 それでも当座の目的には支障ないと判断したのでしょうか。
[128] 移植の動機は従来の表形式の実装では期間外を表示できないことにあった >>81 ようです。 であるとすれば、わずか17年で目的を達し得なくなるのですが、 値が計算不能となるよりは、間違っていても値が得られる方がましと判断したのでしょうか。
[135] ともかく、 Webサイトにあってソースコードにない西暦2017年問題への言及は無視されて配布されたり、 派生版が作られたりすることになりました。
当初Web calendar2のVer0.12bまでは六曜表示に変換テーブルを使用して算出を行っていましたが、テーブルデータのある期間しか利用できないといった欠点がありました。これでは、将来に渡って使用することが困難なため、実際に太陽と月の黄経を計算する方法を模索していました。参考図書を頼りにプログラムを書いてみたのですが、どうも精度上の問題で、朔が午前0時近辺にくると、朔の日付が一日ずれてしまい、その結果、旧暦計算や六曜計算において、実際とは異なる値になり、頭を抱えておりました。
そんな時に林さんという方からメールをいただき、Java Scriptによる旧暦計算プログラムがあることを知りました。またそれは元々はAWKスクリプトの移植ということも分かりました。AWKのソースからPerlに移植し、Web Calendar2 Ver0.20から、このライブラリを使用して旧暦や六曜を計算しています。
本スクリプトの計算精度については、暦計算研究会編の「新こよみ便利帳」に記載の新旧対照表で、2000年から2020年までを確認したところ、2017年2月26日~同3月27日までが、旧暦・六曜表示に誤差のあることが確認されています。
ブラウザ上でスケジュール管理ができるPerlで書かれたCGIフリーソフトです。FIN INC.のWeb Calendarを元に作成し、機能追加を施してあります。オリジナルと区別するためにWeb Calendar2としてあります。今回FIN INC.の許可を得ましたのでソースの公開をいたします。
このページは、Web Calendar2の配布元である"http://www3.biwako.ne.jp/~nobuaki/webcal/"を、「Web システム手帳」が再構成したものです。リンクを除き、ほぼ原文のままになっていますので(2002年ころ)、現在と内容が合わないものがあります。
■Version 0.12b -> Version 0.20の変更点 (2000.6.9)
- ユーザーカスタマイズ機能
- 時計表示や六曜表示、24節気、旧暦表示などについては、クッキーを利用してユーザー側が表示・非表示を指定できるようになりました。
- 六曜を求める際の計算化
- 六曜を求める際に、旧暦計算を太陽と月の黄経を実際に計算するようにしました。従って従来のように六曜の表示に年度の制限がなくなりました。(※制限が無くなったといっても、使用している計算式は略算式なので、未来永劫に渡って使用できるとは限りません。)
- 24節気、旧暦の表示
- 黄経計算を行うことにより、24節気(夏至、冬至、大寒、大暑、その他)と旧暦の表示が可能となりました。
■Version 0.10a -> Version 0.11の変更点 (99.11.10)
- 六曜の表示
- 六曜(大安、仏滅、友引等)を選択表示できるようにした。ただし2007年2月18日まで。19日以降はでたらめに表示されます。
[206] 各種 Perl アプリケーションに組み込まれて普及しました。 また他の言語の移植元にもなりました。
727 名前:721:03/05/25 10:24 ID:8+PhQg1S
perlの場合 ttp://www3.biwako.ne.jp/~nobuaki/qreki/ からスクリプト拾ってきて、
0.07 2017-01-31
0.06 2017-01-31
0.05 2014-02-12
0.04 2014-02-11
0.03 2014-02-11
0.02 2014-02-07
0.01 2013-03-09
出典HP:日めくりカレンダー.com
出典HP:便利コム
上のカレンダーで2月の六曜を見ると、26日は赤口、27日は友引、28日は先負となっています。
しかし下のカレンダーの2月の六曜は、26日は友引、27日は先負、28日は仏滅です。
こうした違いは、3月27日まで続きます。
旧暦2月1日を、上のカレンダーは2月27日としているのに対し、下のカレンダーでは2月26日としているのです。
結論からすると、現在は下のカレンダーが主流となっていて、そちらを使うべきです。
私の提供する印刷用カレンダー作成サイト「カレンダー工房」では、これまで上のカレンダー方式に従っていましたが、プログラムを修正して下のカレンダー方式に基づいた六曜表記に変更しました。
なお、カレンダー工房の旧暦計算は、フリーのqreki.plを基に算出し、誤差を修正するプログラムを独自に追加して六曜を表示しています。
国立天文台の暦計算室によると、2017年2月26日 23時59分に朔(月齢0.0)となります。
どちらもWEBのサイト上にあるカレンダーですが
2017年の「2月26日~3月27日」の間の
「六曜(先勝、友引、先負、仏滅、大安、赤口)」が違っています。
★カレンダーA(出典HP:便利コム)
★カレンダーB(出典HP:日めくりカレンダー.com)
このように、2種類の「六曜」が存在するのを
カレンダーの「2017年問題」と言っています。
上記の「23時58分」は、国立天文台が
実際の月の満ち欠けを観測し、計算上の
月齢を修正した結果なので、当社が扱うカレンダーの
ほとんどのメーカーさんが、この基準でカレンダーを作っています。
しかし、WEBや一部のプログラムでは、この月の計測結果の誤差を
反映していないものがあり、
「2月27日が旧2月1日」となっているものがあるので
2通りのカレンダーができてしまうのです。
当社がお取引している主要なカレンダーメーカーさんでは
「カレンダーA」が「主流」になっています。
「カレンダーB」を採用しているところは、今のところ見あたりません。
[129] Perl の実装としてよく参照されるものがもう1系統あります。 現存しないため、 両者の関係は不明です。
qreki.php (>>53)
を採用。ini\calender_class.php
に
「qreki.phpの処理は遅いので、余計な計算はさせずにバイパス処理をさせる」
と書かれています。qreki.php により変換し、
月中を補間する最適化が実装されています。2006/10/14
と書かれた記事を参照しています。残念ながら
Internet Archive に所蔵されていません。 >>275 が紹介されていたものと思われます。[256]
upk
による
qreki.php
は、
付の
PHP
移植版です。
>>255
[257] AWK 版を参照しつつ、 Perl 版 (>>151) から移植したものでした。 >>255
[258] 「2004-01-23 (金) 16:30:11」 付のコメントがあり >>254、 には既に公開されていたようです。
- function LONGITUDE_SUN()ですが、新こよみ便利帳ver.1.2 p.150にある光行差補正(視黄経)が抜けているようです。 $th += .0048 * cos( $k * NORMALIZATION_ANGLE( 1934 * $t + 145 ) ); $th -= .0057;を追加されると1908年9/25~および2017年2/26~の計算誤差による朔日のズレが解消できます。 -- ephem 2010-09-03 (金) 15:25:30
- 1884は、時差を京都に合わせるため東経135.6333...で計算すると良さそうです。 -- ephem 2010-09-03 (金) 15:31:44
- 以降、JPL DE405で算出した物と比較すると2051/11/3(旧暦10/1)と2177/7/25(旧暦7/1)に朔日の計算がずれますが、2200年までの検証では、ほぼ問題なさそうでした。便利なスクリプトの公開ありがとうございます。 -- ephem 2010-09-03 (金) 15:37:07
と誤りを指摘しました。 >>254
[260]
これを承けて頃に修正する旨と差分が
upk
から投稿されました。
>>254
しかしながら Internet Archive 所蔵のこのページは時点で最終更新がのままで、
qreki.php
の公開日時ものまま変更されていないので、
修正版は更新されなかった可能性もあります。
[261]
残念ながら Internet Archive には
qreki.php
本体はどのバージョンも所蔵されていません。
[262]
指摘があったうち、
,
,
は
JavaScript
版の時点で既に検出された問題の再発見です (>>104)。
JavaScript 版はこの qreki.php
の移植元の Perl 版の移植元に当たりますが、
qreki.php
の配布ページ >>254
からはリンクされておらず、
作者およびコメント者が知っていたのかは不明です。
[263] とは qreki 界隈ではこれが初の報告と思われます。
[264] コメント者がまで検証していながら、 旧暦2033年問題に言及していないのは不思議です。 朔日のチェックだけで月名は見ていなかったのかもしれません。
[265] 不完全とはいえ時点でこうして不具合修正が行われ、 旧暦2017年問題を回避できるバージョンが出現していたのですが、 これが普及しなかったのは不運でした。
tDiary
旧暦六曜表示プラグイン リンク
<item rdf:about="http://310f.com/exocet/hiki/?jqreki.rb">
<title>旧暦六曜表示プラグイン</title>
<link>http://310f.com/exocet/hiki/?jqreki.rb</link>
dc:date2013-11-06T15:55:24+00:00</dc:date>
content:encoded<!<div><h2><span class="date"><a name="l0"> </a></span><span class="title">これは何?</span></h2>
<p>旧暦六曜表示プラグインです。</p>
<p>日記の日付部分に、六曜(大安 赤口 先勝 友引 先負 仏滅)、旧暦の月日を表示します。</p>
<h2><span class="date"><a name="l1"> </a></span><span class="title">インストール</span></h2>
<p>qreki.rbをjqreki.rbからインクルード出来る場所にコピーしておく必要があります。</p>
<h2><span class="date"><a name="l2"> </a></span><span class="title">使い方</span></h2>
<p>「基本」-「表示一般」-「日付フォーマット」で、以下を指定します。</p>
<ul>
<li>%R … 六曜(大安 赤口 先勝 友引 先負 仏滅)</li>
<li>%Q … 旧暦の月</li>
<li>%q … 旧暦の日</li>
<li>%S … 二十四節気</li>
</ul>
<h2><span class="date"><a name="l3"> </a></span><span class="title">ダウンロード</span></h2>
<div class="plugin">{{attach_anchor_string("添付:jqreki_20131106.zip","jqreki_20131106.zip")}}</div>
<h2><span class="date"><a name="l4"> </a></span><span class="title">備考</span></h2>
<p>誰かキレイに書きなおしてくれ~。</p>
</div>></content:encoded> </item>プラグインフォルダに入れるだけで動きます。あとは日付フォーマットで%Rと書くと、その部分が対応する六曜に変換されます。動かすには
calendar(暦計算モジュール) リンク と付属しているcalclass.rbが必要です。
[593] また別系統の移植版。 ただの移植ではなく天体暦が置き換えらえている。 同じ人が近い時期に qreki ベース以外の2手法でも似たようなものを作っていて、 結果を比較していたらしい。
[594] しかし gem として公開されていて、それなりにダウンロードされて使われている模様。 qreki 版も (他手法に比べて精度はよくないと評価したにも関わらず) 本段落執筆時点でまで定期的にメンテナンスされている。
0.3.2 - May 25, 2021 (18KB) 0.3.1 - November 04, 2018 (17.5KB) 0.3.0 - September 15, 2016 (17.5KB) 0.2.8 - July 27, 2016 (17.5KB) 0.2.7 - July 27, 2016 (17.5KB) 0.2.6 - July 20, 2016 (18.5KB) 0.2.5 - July 20, 2016 (18.5KB) 0.2.4 - June 15, 2016 (18.5KB) 0.2.3 - June 15, 2016 (18.5KB) 0.2.2 - June 10, 2016 (18.5KB) 0.2.1 - June 10, 2016 (19KB) 0.2.0 - June 10, 2016 (19KB) 0.1.2 - June 09, 2016 (19KB) 0.1.1 - June 08, 2016 (19KB) 0.1.0 - June 08, 2016 (19KB)
(31)2008.6.3 v2.2
・計算精度向上を狙って浮動小数点関数に変更(iappli浮動小数点版)
・六曜表示追加(iappli浮動小数点版)
(33)2008.6.26 v2.22
・浮動小数点関数は遅い為j3d.Mathに戻す(iappli浮動小数点版)
(34)2008.6.26 v2.23
・j3d.Math版六曜ルーチンにバグがある為、浮動小数点版に戻す(浮動小数点版)
携帯潮汐に組込んでいたDoja iappli版
「旧暦六曜Javaソースプログラム」 リンク を要望が多い?ので公開する。
内容を理解せずに移植しているので計算結果は責任が持てません!
暦の2017年問題、判明したのは携帯ワイド改を使って頂いている漁師さんからのバグ報告でした。 下記の自作androidアプリは暦を表示してる。
・携帯潮汐改
・携帯潮汐Ⅳ
・潮汐ワイド改
・潮汐ワイドⅣ
・KoKoDoKo日の出月の出
自分はいままで高野英明氏作jgAWK版をJavaに移植した(B)パターンを使っていましたが主流は(A)パターンのようです。
それでWeb上を探し回って(A)パターンのかわうそ氏作のJava Script版を見つけましたのでJava版に移植させて貰いました。
本ソフトは高野氏が作成した「旧暦計算サンプルプログラム QRSAMP」と長野隆氏が作成した旧暦計算 JavaScript(ECMAScript) Library "qreki.js"をVisual Basicに移植した旧暦を表示するサンプルソフトです。
nakodate.dll2005/05/01 version 1.19
・旧暦の年計算ルーチンに間違いがあったので修正。
2005/04/27 version 1.18
2005/04/27 version 1.17
・『旧暦変換』『五曜取得』『年ノ干支取得』『日ノ干支取得』命令を追加。
// 旧暦計算ライブラリ // 作者:クジラ飛行机(2005/04/27)http://www.kujirahand.com //----------------------------------------------------------------------- // オリジナルのスクリプトは高野氏のAWKです。下記より入手できます。 // http://www.vector.co.jp/soft/dos/personal/se016093.html //----------------------------------------------------------------------- // オリジナルよりの改良点: // 2017年の計算誤差をDB参照により修正 // 但し、旧暦2033年の計算誤差は、そのまま // 検証年:2017,2005
概要 (クジラ飛行机) [2005年04月28日]
日付Sから旧暦を求めます。計算から暦を計算しているので、完全に正しいものを得ることはできません。分っているものでは、旧暦2033年が正しく計算できません。
※現在確認したところ、2009年9月の20-23日が間違っています。
大化元年から明治5年までは『日本暦日原典』を参照。また、『国立天文台 暦計算室』の計算結果の校訂を参照。
明治6年以降については、なでしこの旧暦変換で作成。 (なでしこの旧暦変換には問題がありましたが、朔の日付と閏については正しく取得されており、こちらのデータには問題ありません。旧暦変換で問題のあった日付について、正しい出力を確認しています)
2033年問題については『暦文協』の見解に基づき閏11月案に修正。
README.md QREKI.AWK と qreki.py は新暦1年1月1日から9999年12月31日までの間で 同じ結果が得られることを確認しています。 過去や遠い未来にたいして適用する是非はともかく。
README.md の記述を見たら、
あたかも正確性が検証されたよいソフトウェアのように読めてしまいます。
(移植の正しさの検証としては間違っていないのですが。)
同梱されているオリジナル版のドキュメントにはの問題が明記されているのですが、
表にこう書いてあったらそんな細かいところまでチェックしない人の方が多いのではないでしょうか。qreki.cpp,
https://web.archive.org/web/20111201003535/http://csaori.googlecode.com/svn-history/r243/trunk/impl_saori/timebkn/qreki.cppNSCalendarIdentifierChinese
の結果と Python
の結果をからまで比較し、
の閏月の違いと、
の朔の違いを検出。NSCalendarIdentifierChinese は農暦の実装なので、
旧暦と違う結果になるのは当然。
Apple の公式ドキュメントにも旧暦とは書いていない。// 旧暦の2017年問題で, 新月になる旧暦2017年2月1日は // 新暦2月26日23時58分ですが,これを2月26日とするか27日にするか // という問題があり,本プログラムでは2月27日となります。 // // もし,新暦2017年2月26日を旧暦2017年2月1日とみなす場合, // 求められた日付を以下のようにずらす必要があります。 // // 1/30→2/1, 2/1~2/29 →2/2~2/30
このプログラムは、高野英明氏のQREKI.AWKを勉強をかねてrustに移植したものです。 2020年1月1日から2050年12月31日までQREKI.AWKと同じ結果が得られることをテストしておりますが、正確性を保証するものではありませんのでご注意ください。
このプログラムのもとになったqreki.awkとqreki.docをsrc/qrsamp11に同梱しております。 また、同じくpythonに移植されたIto Shunsuke氏のqreki_pyを大変参考にさせていただきました。
Go言語、Go言語のテスト、Go言語のモジュール作成を学習するため、qrekiをGo言語により再実装を行います。
[304] その他、 サーバー側で実行されソースコードが公開されていないものの、 qreki 由来と明記されている、または挙動が qreki と同じものもたくさんあります。
[333] 旧暦の「きゅう」に「Q」を宛てたネーミングセンスも qreki の普及の一因かもしれません。
[334] 誰でも思いつきそうなもじり方ですが、同名の別のソフトウェアは案外ありません。 (qreki が有名すぎて同じ名前にしづらかったのかもしれません。) (qreki のコードは継承せず名前だけ継承したものはいくつかあります。)
[336] から 「25年以上前」 >>342 ないし 「20年以上前」 >>335, >>344 にQ暦という PASCAL で書かれた MS-DOS 用ソフトウェア Q暦 がありました。 当時「めずらしソフトで話題にもな」ったといいます。 >>335, >>344
[337] 逆算すると昭和時代末期にあたります。 AWK 版の QREKI 初版がですから、それより5年以上前となります。
[338] 作者は Q と名乗っています。 >>335, >>342 ソフト名と作者名はどちらが先立ったのでしょうかね。掛かっていたのかもしれません。 同じ作者の他のソフトウェアも名前に「Q」が入っています。
[343] に Q が C# で開発した Windows や Windows CE 向けのカレンダーソフトウェア NiQ に六曜表示の要望があり >>342、 旧暦、六曜、二十四節気の表示に対応しました >>339。
[345]
、
旧暦表示のみが
Q暦(復刻版)
(QReki.exe)
として公開されました。
>>344
[346] NiQ の旧暦への変換には .NET Framework を使っているようです >>342。 Q暦 (復刻版) も同様と思われます。 従って AWK 版 QREKI の系譜のソフトウェアとは異なる結果が得られるはずです。
[349] 残念ながら、 古い Q暦 は配布されていません。当時のパソコン通信で配布されていたのでしょうか。 Q暦 (復刻版) も Internet Archive に所蔵されていません。 NiQ も旧暦に対応した後の版は Internet Archive に所蔵されていません。
[350] 『Q暦カレンダー01401』直島・豊島・小豊島(香川県)の旅行記・ブログ by 52市村康さん【フォートラベル】, 52市村康, 2014/01/01 - 2014/01/17, https://4travel.jp/travelogue/10851024
[74] 誤っているとはいってもこれだけ広まってしまったとなると、 現代日本の暦文化の1つの側面として無視できない存在といえるのではないでしょうか。
[75] 日本のソフトウェア開発史の視点でも qreki は興味深い事例ではないでしょうか。 パソコン通信の文化で生み出されたソフトウェアで、 この令和の時代まで未だに現役で使われ続けているものは、 他にほとんどありません。 有名所では LHA が qreki を遥かに凌ぐレベルで普及していましたが、 平成のうちに ZIP に駆逐されてしまいました。 なぜ qreki は未だに生き残っているのでしょう?
[76] MS-DOS 向けの旧暦計算ソフトウェアは他にもいくつかありました。 ソースコードが公開されていたものも、いくつかあったようです。 なぜ qreki だけがこれだけ多くの環境に移植され幅広く使われるようになったのでしょう?
[79] 平成後期の時点では、Google検索で旧暦の計算や変換のプログラム・ライブラリーを探そうとすると、 上位に qreki のドキュメントや移植版が表示される状態になっていました。 プログラミング言語の標準ライブラリーで旧暦を求められないことを知った技術者が、 既存のライブラリーがないかと検索し、 上位に出てくるそれっぽいコードをそのまま信用してしまった、 といったところでしょうか。
[394] 比較的緩いライセンスでソースコードが公開されて、 中央管理されずにあちこちで分散して利用された。 という模範的ともいうべき民主的なソフトウェア開発が完全に裏目に出ている。
[395] みんな敬意を払うつもりなのか直接の移植元でもないはずの上流の配布サイトにリンクしているのに、 そこに書いてある注意事項とか全然読んでいない。動くコードがあればそれでいいって?
[396] オリジナルのドキュメントに 「オリジナルのスクリプトと本説明書を必ず同 梱して下さい。」 って書いてあるのにそれを真面目に履行してるやつはあんまりない。 ちゃんと同梱して利用者がみんな読んでいればもう少し状況はマシだったのかもしれないが。
[397] 他のライセンスで配布してる派生ソフトウェアまであるけど、原作者に許諾を得ているか甚だ怪しい。
[610] 既に移植版があるのを知ってか知らずか、 オリジナルから再移植する人も多い。 みんな律儀にオリジナルを紹介しているので、 どうせならオリジナルから移植するのが一番正しく動作するだろうと思ってなのかな。 (再移植したくなった動機を教えて欲しいが書かれていない。) オリジナルがちゃんとメンテされてればそれで良かったのだけど、 そうでないのが仇となって既存移植版が修正したり注記したりしてるのを再移植版が無視している。
[611] というか古い移植版ほど結果の正しさに注意を払って、対処できなかったとしてもそれをちゃんと書いているのに、 新しいものはそれを怠っているのが多い。作りました!と書くだけで正しいか検査しました!と書いてない。(書いてないのはしてないからだろう。) 「結果は保証しません」とは書くくせに。保証しなくていいから努力はしてくれよ。
[612] 時間をかけて沢山の人の目と手が加わることが、 蓄積ではなくリセットになってしまっている。辛い現実。
[440] 本当は利用者の総数も知りたいけど推計するのも難しい。 しかし派生版を開発する人や紹介する人の数を見ただけでも、 このソフトウェアが惹きつけたエネルギーの大きさははかり知れるというもの。
[316] そういえば qreki の C# 移植版はみつかりません。 標準ライブラリー (.NET Framework) が旧暦に対応しているからなのでしょうね。
[540]
Objective-C や Swift の移植版がないのも示唆的。
Apple の Foundation は農暦に対応していて、
旧暦には対応していないにも関わらず、
Swift で旧暦を表示するには Chinese と指定する、
という情報が出回っている。
(これはこれで別の問題が...
[614] 太田本郷城跡出土の墨書かわらけ, 古川, , https://www.city.toyama.toyama.jp/etc/maibun/toyamajyo/sengokukisiro/oota-bokusyo.htm
16世紀後半頃使われていた暦は、太陰暦に基づく「長慶宣命暦」です。この暦は、貞観3(861)年から貞享元(1684)年まで使用されました。太陰暦では大の月と小の月があり、閏月が入ることもあります。大の月は晦日が30日であるのに対し、小の月の晦日は29日という違いがあり、年によって異なります。
高野英明氏による旧暦計算を用いると、太田本郷城が記録に表れる元亀3年から天正6年までのうち、8月が大の月なのは、元亀3、天正元、天正2、天正3年の4年であり、上杉方が拠っていた時期にあたります。
[615] このウェブページの解説文は、 「高野英明氏による旧暦計算」 を使っていますが、それがいつどのように発表されたものかは明らかにされていません。
[616] ウェブ検索による限り、 「高野英明」 による旧暦の業績は qreki しか知られていません。
[617] もしこの解説文が qreki に依拠しているとすると大問題です。 qreki は現行旧暦の実装であり、過去の暦法の実装ではありません (>>26)。 この解説文の著者は最初の段落で暦法の違いを認識しているにも関わらず、 暦法が明らかに異なる計算結果を使って立論していることになるのです。
[625] >>624 この調査報告書に同内容の記載がありました。 >>624 #page=22 こちらには出典がはっきり書いてあって、 まさかの qreki でした。 >>624 #page=23