• [90] かつてはここにあったとされる。 >>87 の古い版と思われる。
• [91] 旧暦関連の記述は Internet Archive に現存せず。

• [284] カレンダーと暦注を Webページに表示する CGIスクリプト (サーバー側: Perl, クライアント側: JavaScript)。
• [291] その時代に作られた他の Webサイトでたまに見かけます。
• [293] qreki.js が組み込まれています。

• [402] 日付が少し遡るが >>400 か。

• [238] 2007-01-31T13:20:55.000Z, 2022-07-13T08:03:33.813Z http://www2s.biglobe.ne.jp/~yoss/tpircs/qreki.js
• [438] 「令和への改元。祝日の異同(2020年現在)に対応しています。」
• [399] >>400 に近い (が違う)。

• [237] Internet Archive によれば 2013-03-29時点で既に 404、それ以前の所蔵なし。
• [239] 2008-01-28時点では稼働していたらしい (>>233)。

• [434] カレンダー「有効範囲は今年度のみです。他年度は正確ではありません。」 (独自実装)
  • [435] 旧暦カレンダー, 2022-07-14T10:30:11.000Z, 2021-12-07T19:32:40.532Z https://web.archive.org/web/20211207193229/http://www2s.biglobe.ne.jp/~yoss/tuki/kyureki3.html
    • [436] 「2033年12月22日 閏11月1日説に書き換えました。」 (独自実装)
  • [437] これより前はカレンダーも qreki か?
• [241] 日付変換 「このスクリプトは旧暦計算サンプルスクリプト 原作は高野英明氏、 JavaScriptに移植が旧暦計算スクリプト Version 1.5長野 隆氏によるものです。 このスクリプトは2033年閏7月を採用しています。 」
• [432] 2021-03-17T03:31:52.000Z, 2022-07-14T10:17:40.073Z http://www2s.biglobe.ne.jp/~yoss/tuki/js/qreki.js
  • [433] 1.5 から編集されていて同じではない。

• [635] コリドラス産卵予報スクリプト β版, koribee, 2007/02/06(火) 23:50
  • [636] JavaScript 版 (>>92) からの派生
  • [637] AWK 版を参照

• [639] コリドラス産卵予報スクリプト Ver.1.0, koribee, 2007/02/11(日) 00:23
  • [638] 「v1.0 公開 2007.2.10」
  • [623] 配布ファイル現存せず

• [642] 実際含まれるコードは月齢の略算式だけで、 旧暦日付の計算・表示は行われない。

• 六曜の取得について検索しているとこちらの記事がヒットし、大変ためになりました。

  こちらのソースの改変・二次利用についてなどライセンスはありますか?ぜひ使わせていただきたいです

• ここは、タイトル通り私のゴミ箱です。捨てて置いたのですからお好きにどうぞ。

  もしあなたがこのコードでボロ儲けしたのなら、おすそ分けを…。^^;

• [83] オリジナルの Web Calendar は Internet Archive 所蔵のソースコードによると旧暦、六曜に未対応。

• このページは、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日以降はでたらめに表示されます。

  • [85] qreki 化以前の版は Internet Archive 等にも所蔵なし。

• [414] どれかは不明。

• [422] 「DOS時代に「today 今日は何の日」というのがあった。」
• [423] TODAY を思い出した(?)のが開発の端緒らしい。

• [424] つぶやき/2009-3-16 - Sign-G::FsWikiの自己流かすたまいず, 2022-07-14T10:06:14.000Z http://sign-g.sakura.ne.jp/Wiki/wiki.cgi/OwnCustomize?page=%A4%C4%A4%D6%A4%E4%A4%AD%2F2009%2D3%2D16
  • [425] 「ベクターで旧暦の算出方法をソース付きで見つけた。」 「しかし完全フリーではないようなので,このままPerl化するのもどうかと考えて,テーブルを参照する形でいいかなと考えた。」
  • [426] 表の出典は VB 版か?

• [428] 「根気よく捜せばPerl版も見つけてしまったのだな。」

• [420] 干支対応が VB 版由来。

• [430] 「モジュールqreki.pmに,与えられる日付から十二宮を0~11の値で返す機能を追加。」
• [431] この変更は未公開?

• 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

• [210] 本項執筆時点での最新版は2021-03-25。
• [211] 旧暦計算法部分は2013-03-09以来大きく変更されていない。

• [410] Wikipediaの旧暦2033年問題への言及が追加。

• [547] にゃぶぅ🎹さんはTwitterを使っています: 「計算がおっそい理由は、元のawkスクリプト由来で、cos関数に渡す角度をすべて360度に正規化する処理を入れているせい。 Perlのcos関数は、360度を超える値を渡しても正常に計算してくれる。 awkは違うのカナ?」 / Twitter, 午後9:20 · 2019年3月21日 +09:00, 2022-07-15T10:09:12.000Z https://twitter.com/Nyaboo/status/1108705050811981824
• [548] にゃぶぅ🎹さんはTwitterを使っています: 「Date::Qrekiの太陽の黄緯を求める計算、間違ってるっぽい。 係数 * cos(係数 * t + 係数)ってのを積算するのだけど。 0.0048 * t * cos(35999.05 * t + 267.52) は、cosの外でtを乗算しちゃあいけない、はず。 0.0048の係数のおかげで誤差に埋もれて、結果は(ほぼ?)変わらないみたいだけど。」 / Twitter, 午後9:48 · 2019年3月21日 +09:00, 2022-07-15T10:09:12.000Z https://twitter.com/Nyaboo/status/1108712005249097729

• [140] 2017年2月カレンダー - 日めくり!カレンダー.com, 2022-06-20T08:44:42.000Z https://www.himekuricalendar.com/month-calendar-2017-02
• [141] 2017年大安カレンダー【平成29年】日めくり!カレンダー.com, 2022-06-20T08:45:44.000Z https://www.himekuricalendar.com/taian2017

• [143] 2017年大安カレンダー - 日めくりカレンダー.com, 2022-06-20T13:47:49.000Z, 2016-08-31T08:07:39.847Z https://web.archive.org/web/20160831080737/http://www.himekuricalendar.com:80/taian2017
• [145] このサイトの実装が qreki の系譜かどうかは不明。

• [183] 2017年大安カレンダー - 日めくりカレンダー.com, 2022-06-20T13:48:23.000Z, 2016-09-12T09:48:45.924Z https://web.archive.org/web/20160912094819/http://www.himekuricalendar.com:80/taian2017

• [181] >>138 と記事内容がよく似ているが、関係性は不明。
  • [185] >>138 とは上下 / AB が逆転している。
• [182] こちらの記事には怪しげな記載が多い。 こちらの著者はカレンダー業者 (つまりプロ) のはずだが...? (>>138 はまあ妥当な内容。)

• [115] Internet Archive 所蔵は2003-04-25が最古。

• [449] 言及がある最古。2003-02-10。 これの前の2003-01-29版には言及なし。

• [575] 統一教会。大韓民国の旧暦を併用している宗教団体。 統一教会暦

• [357] ini\calender_class.php に 「qreki.phpの処理は遅いので、余計な計算はさせずにバイパス処理をさせる」 と書かれています。
• [358] 月初と月末を qreki.php により変換し、 月中を補間する最適化が実装されています。

• [456] ここまで、 Internet Archive にも現存しない。

• 公開中

• [459] Internet Archive にも現存しない。

• [459] Internet Archive にも現存しない。

• 公開中

• [466] AWK 版を参照している。
• [468] 現時点 (2022-07-14T13:59:36.100Z) での最新は2020-12-19

• [464] PHPで日本の祝日、旧暦を扱えるライブラリを作った - Qiita, @suzunone, 投稿日 2018年05月19日, 2022-07-14T13:43:45.000Z https://qiita.com/suzunone/items/949e71ea7ea86630524f
  • [465] 「....のは、2005年の7月のことでした。」 「なんか、天皇誕生日とか変わるらしいし、元号も変わるらしいので、バージョンアップを兼ねて、PHP7化とComposer,Phanに対応しました。」 「もともとは、PHPのMLに投稿させていただいて、 その後私の自作フレームワークの派生プロジェクトとして細々と更新を続けていたものとなります。」
  • [467] その「PHPのML」がどこかは不明。

• [202] Rokuyou, chameleon
  • [203] ファイルの日付: 2005-08-13
  • [204] オリジナル版から PHP (WordPress プラグイン) に移植したもの。

• [272] 理解していないならこんな余計なことを書くべきではなかった。 社会的に広く受け入れられているわけではない特定のグループの主張について、 それに賛同しているわけでもないのに、 それに迎合するような態度を実装者が取るのはおかしい。
• [273] こういうちょっとしたことの積み重ねで、 間違った認識が広がって、いつの間にかそれが事実に変わってしまうのだ、 というのがこの qreki と旧暦2017年問題から得られる教訓。
• [296] この手のクレーマーに目をつけられたら大変だから、 何か断り書きでも書いておかねばと思ったのかもしれません。 そう考えると自己防衛に走った人を責めるのは酷というもの。 暦の受容の負の歴史の一頁として、 こういう事案も忘れてはいけませんね。

• [275] qreki.php は2006-10-14付。

• [281] 作者自身の紹介記事。
• [277] 「先日PHPに移植した旧暦計算ライブラリ」 として URL に 2006/10/14 と書かれた記事を参照しています。残念ながら Internet Archive に所蔵されていません。 >>275 が紹介されていたものと思われます。
• [278] >>151 を引用して、旧暦2017年問題がある旨を注記しています。

  • まあ、10年以上も先の話ですので、それまでに解決策が見いだされているのではないかと思われます。 というよりそもそもそこまでこのプラグインが使われ続けることもないのかな?

    より精度の高い計算法をご存じの方がいらっしゃいましたら、教えてください。

  • [279] なぜその重要事項を >>266 や >>275 に書かないのか...

• [283] 利用者。

• [461] >>53 から派生

• [306] AWK 版を参照しつつ、 PHP 版 (>>53) を使っていると書いてあります。
• [307] AWK 版ドキュメントを引用してその正確性や西暦2224年2224の問題を紹介し、 Perl 版 (>>27) を引用して旧暦2017年問題を紹介していました。
• [310] 「2007-04-01T12:00」
• [311] 「2007-04-04T16:00」 「2007-04-08T02:50」 (旧暦計算に関係ない変更)

• [309] このドキュメントは当時 Google検索で上位に現れていました。

• [388] 「また何か行事を執り行ううえでは、大安や仏滅といった暦も大切ですよね。しかし六曜を知るには旧暦の日付を計算する必要があり、そのためには前年の冬至から翌年の雨水までの二十四節気と、朔日の日付を求める必要があるらしく、スクリプト内で真面目に計算するのは大変だと判断しました。都合の良いことに旧暦の日付を求められるWeb APIが公開されていますので、今回はこちらを利用させてもらいました。」

• [224] 2022-07-13T07:16:19.000Z https://web.archive.org/web/20121212060637/http://fujikoweb.net/php/qreki_01.txt
• [225] >>221 用の UI

• [473] Internet Archive 最古、 2005-11-23
• [474] 旧暦_月齢, 2022-07-15T03:19:51.000Z, 2006-01-05T20:37:14.734Z https://web.archive.org/web/20060105203537/http://www7.big.or.jp/~fujiko/php/qreki.php
• [475] 2022-07-15T03:20:24.000Z https://web.archive.org/web/20060225051546/http://www7.big.or.jp/~fujiko/php/qreki.inc.txt

• [478] 「年から24節気を、日から月齢を、月数字から六曜を、月文字から月暦を検索… 」
• [477] 同じWebサイトのカレンダー。 西暦2001年2001から西暦2020年2020に対応。
• [479] ソースコードが見つからず (非公開か?) 実装方法不明。

• [219] 旧暦計算プログラム 設置方法。, ☆(ステラ), 2008年1月29日(火)
  • [222] >>220, >>221, >>224, >>225 の利用方法を紹介
• [226] - ぽちぽちぼちぼち。, 2022-07-13T07:22:16.000Z http://fuji3.main.jp/MT/archives/2007/01/2007-01-20.php
  • [227] 今日って大寒だったのか!, ☆(ステラ), 2007年1月20日(土)
    • [228] AJNET のカレンダー (旧暦表示あり) を参照している。
    • [229] 「それにしても、どこかに『月齢&旧暦カレンダー』ブログパーツってないかなぁ。月齢だけならいくつか見るのだけれど。」
• [230] - ぽちぽちぼちぼち。, 2022-07-13T07:24:12.000Z http://fuji3.main.jp/MT/archives/2008/01/2008-01-28.php
  • [231] 旧暦 六曜 月齢 二十四節気 カレンダー。, ☆(ステラ), 2008年1月28日(月)
    • [232] 「両方入っているのが見つからず、とりあえず「お月様(月齢表時)」だけでも…と設置して、その他は先送りになっていたのです。」
    • [233] JavaScript 版 (>>88, >>234)、 Perl 版 (>>151)、 別の PHP 版を参照しつつ、 PHP 版を採用したとのこと。

• [165] 平成17(2005)年2005時点で既に失われていた >>158。

• [156] 六曜プラグインというのはどうか, 2005年11月16日 水曜日 https://web.archive.org/web/20070728222052/http://www.310f.com/exocet/tdiary/20051116.html#p05

• [481] jroku.rb。
• [159] 引用記事の題名のリンク先は >>156。
• [160] >>149 で配布されていたのはここで作られたものか? しかしファイル名は一致しない。日付もぜんぜん違う。
• [166] calendar(暦計算モジュール)は別記事参照。 qreki の系譜でなさそう。
  • [480] Ruby 版 (>>162) 及び Ruby-Luna を見つけたが入手不能で利用できなかったとのこと。

• [152] 2013-11-14が最初の版。
• [153] AWK 版が参照されている。

• [154] AWK 版が参照されている。
• [483] qreki | RubyGems.org | コミュニティのGemホスティングサービス, 2022-07-15T06:00:24.000Z https://rubygems.org/gems/qreki

• [384] 補足
  • [381] 「上記のライブラリを利用すると2017年の2〜3月の一部の六曜が流通されているものと異なる値が得られることを確認した。これは月齢の計算が古いので上記の期間に狂いが生じている。」
  • [382] 「また、2033年秋から2044年一部にかけての期間は、六曜が正しく計算できない期間が存在していることがわかっているので、六曜は2032年まで計算するように使うのがいまのところベター。また、ライブラリの信頼性は定期的に確認する必要はある。」
• [383] Wikipedia の旧暦2033年問題を参照している。
• [385] 約1ヶ月後に間違った結果になることを確認しているのに、それは「補足」 に過ぎず、この記事の著者にとって当該ソフトウェアを使わない理由にはならないらしい。 (不具合の指摘の記事ではなくライブラリーの紹介記事。)
• [386] 「ライブラリの信頼性」 を疑う姿勢は素晴らしいが、 疑った結果信頼できないとわかっても採用・紹介を憚らないというのが新感覚すぎて理解しがたい。 非難とかでなく本当にわからない。

• 「計算対象年は 2008 年〜 2016 年。」
• [577] GitHub - komasaru/eph_jcg: Ephemeris calculation tool by JCG method., 2022-08-27T02:57:46.000Z https://github.com/komasaru/eph_jcg

• [582] 海上保安庁サイトおよび >>576 を「精度が高い」と紹介。
• [583] DE430 および >>587 を「より高精度」と紹介。

• [586] 「当リポジトリは更新停止。(2018年11月4日)」

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)

• [591] 「但し、微調整はしているものの、このアルゴリズムは略算式を使用しているため、当然ながら若干の誤差が発生します。 そこで、 NASA の機関 JPL(Jet Propulsion Laboratory) の提供する太陽・月・惑星の正確な位置データ DE430 などを使用して計算する RubyGems ライブラリを作成しました。」

• [196] オリジナル版を iappli Doja 用の Java に移植したもの。
• [186] リンクされたソースコードは Internet Archive に無し。

• [484] AWK 版から派生。

• [187] 旧暦六曜計算Javaソースプログラム, 大和, 2017-03-08T03:02:42.000Z, 2022-06-20T13:52:07.786Z http://ave.la.coocan.jp/kaihatsu/qreki.htm
  • [188] 移転先。
  • [189] >>78 時代にはなかった西暦2017年問題の解説が追加されている。
    • [190] >>180 を参照している。
    • [199] A/B の区分は >>180 と同じ。
  • [191] 「Aパターン」「Bパターン」の2種類のプログラムが配布されている。
  • [192] 「Aパターン」 はかわうそ@暦 の 2008/01/05 版の JavaScript を Java に移植したもの。
    • [486] ソースコードのファイルの日付は2017-03-08。
    • [193] qreki の系譜では無い。
  • [194] 「Bパターン」 はオリジナル版から Java に移植したもの。
    • [195] >>78 で配布されていたものと同じか。
    • [197] ただしソースコードのファイルの日付は2017-03-08。
    • [299] ファイル内のコメント 「Java版 旧暦六曜計算プログラム by 大和」

• 暦の2017年問題、判明したのは携帯ワイド改を使って頂いている漁師さんからのバグ報告でした。 下記の自作androidアプリは暦を表示してる。

  ・携帯潮汐改

  ・携帯潮汐Ⅳ

  ・潮汐ワイド改

  ・潮汐ワイドⅣ

  ・KoKoDoKo日の出月の出

  自分はいままで高野英明氏作jgAWK版をJavaに移植した(B)パターンを使っていましたが主流は(A)パターンのようです。

  それでWeb上を探し回って(A)パターンのかわうそ氏作のJava Script版を見つけましたのでJava版に移植させて貰いました。

  • [200] 西暦2017年問題の解説は >>189 と同じ。

• [319] AJNET の旧暦および国立天文台の朔を参照している。

• [321] 本家はちょうど前日に修正されているが (>>198)、 それを知らずに独立して修正したものか。

• [323] 「自分用の暦アプリ」は非公開と思われ、著者のサイト等には見当たらない。 スクリーンショットのみ。 2022-07-14T02:41:36.600Z

• [325] 旧暦2033年問題は言及しているだけで修正していない模様。

• [512] 1.18, 1.19 のバイナリーパッケージが配布されています。
• [513] ソースコードは無し。
• [514] LGPL で配布されていたようなので、 当時のソースコードは探せばどこかに残っているかも。 1.17 は 1.18 と同日なので流通しなかったのかもしれません。

• [519] AWK 版から派生した Delphi (Object Pascal) 版。
• [516] 2008-10-10時点が GitHub の最古。
• [518] 旧暦が間違った日付を出力する問題 (@955), @955, 2021-07-11 00:05:29 +09:00, 2022-07-15T08:57:55.000Z https://github.com/kujirahand/nadesiko/commit/dd37f503a50e3a358df60e7c83168e974549b17c
  • [524] 「2021/07/10 version 1.582」にこれが反映されている。
• [517] @955 旧暦変換の問題を修正, @955, 2022-02-08 11:13:36 +09:00, 2022-07-15T08:57:39.000Z https://github.com/kujirahand/nadesiko/commit/b654bff6ad4db48cd4faf952af2b9eba36eaa72c
  • [525] 「Windows版 v1.586 (2022/02/08)」にこれが反映されている。

• [523] 旧暦変換がおかしすぎる(六曜も), 雪乃☆雫, 2021-06-03 09:23
  • [526] 本家 qreki とは別次元でおかしな結果が得られるとのこと。 移植によるミスか。
• [531] ちょっとやってみます~, 雪乃☆雫, 2022-01-04 16:30
  • [532] 「データを使う方法の強みは、歴史上の実際の暦と結果が合う点ですね。 しかし、データがある範囲内しか取得出来ないんですよね~(モノスゴイ未来の旧暦なんて、あまり需要は無さそげなうえ、計算でも誤差の予測が難しくなるからどのみち正確には算出できないとは思いますが) とりあえず、それで良ければv1で動くようにしてみます!」

• [528] なでしこv1 の実装。 qreki ベースではなく表を使う。 旧暦645年1月1日kyuureki:0645-01-01から2099-12-31に対応。

  • 大化元年から明治5年までは『日本暦日原典』を参照。また、『国立天文台 暦計算室』の計算結果の校訂を参照。

    明治6年以降については、なでしこの旧暦変換で作成。 (なでしこの旧暦変換には問題がありましたが、朔の日付と閏については正しく取得されており、こちらのデータには問題ありません。旧暦変換で問題のあった日付について、正しい出力を確認しています)

    2033年問題については『暦文協』の見解に基づき閏11月案に修正。

• [529] 標準ライブラリーの誤りを指摘した者による代替実装。 2022-01-17, 2022-01-18
• [533] これが開発されても標準ライブラリーが置き換えられないのは、 表ベースより計算の方が良いという考えによるものか。

• [535] 2022-07-15T09:33:13.000Z https://n3s.nadesi.com/image.php?f=24.json
• [536] なでしこv3用の実装。これも表によるもの。

• [538] なでしこv3用の表。 (実装はない。) 2022-06-08

• [117] AWK 版, JavaScript 版 (>>88), Perl 版 (>>15), Ruby 版 (>>147), PHP 版 (>>53), PHP 版 (>>266), Java 版 (>>13) を参照している。
• [379] 「動作が同じということと、算出結果に誤りがないかどうかは別問題。詳しくはオリジナルの QREKI.DOC に。」

• [48] fgshun/qreki_py: 旧暦と六曜を計算 (2019-03-15 10:54:06 +09:00) https://github.com/fgshun/qreki_py

  • QREKI.AWK と qreki.py は新暦1年1月1日から9999年12月31日までの間で 同じ結果が得られることを確認しています。 過去や遠い未来にたいして適用する是非はともかく。

  • [376] オリジナルのドキュメント (>>70) も同娘されてはいます。
  • [377] この README.md の記述を見たら、 あたかも正確性が検証されたよいソフトウェアのように読めてしまいます。 (移植の正しさの検証としては間違っていないのですが。) 同梱されているオリジナル版のドキュメントには西暦2224年2224の問題が明記されているのですが、 表にこう書いてあったらそんな細かいところまでチェックしない人の方が多いのではないでしょうか。
  • [378] 「過去や遠い未来」 については留保が付いていますが、 もっと近い過去や未来について、 作者は何も把握していなかったということでしょうか (>>117 では JavaScript 版, Perl 版に言及していたのに)。 せめてオリジナルに言及がある西暦2224年2224くらいははっきり書いておくべきでした。 (>>379 には少しだけ言及があったのに。)

• [545] fgshunさんはTwitterを使っています: 「cjholiday と qreki_py に Python 3.8 の Argument Clinic をつかってさらに速度を上げるようとする試み。ブランチ名 clinic38 。中身が分岐の羅列にすぎない前者は引数パースが実行時間に占める割合が大きいらしく加速した。いっぽうそれなりに演算している後者には有意な速度差はみられない」 / Twitter, 午前1:09 · 2019年10月20日 +09:00, 2022-07-15T10:08:47.000Z https://twitter.com/fgshun/status/1185588712345747457

• [543] fgshunさんはTwitterを使っています: 「np.sum(a * np.cos(np.pi / 180.0 * (k * t + th))) numpy で書いてみる。λsun=Σ A*cos(k*t+θ0 ) をそのまま書くことができて、高速で動く。そりゃそうだよな」 / Twitter, 午後9:15 · 2020年2月17日 +09:00, 2022-07-15T10:07:58.000Z https://twitter.com/fgshun/status/1229378883188748290

• [482] 0.4.6

• [370] 「「こどもの日(5/5)は仏滅となる事はない」というまことしやかな噂を聞き確かめたいという気持ちが芽生えた。」
  • [371] そんなひどいデマがあるのか。当然結果は偽。
  • [373] Python 版を使って西暦1980年1980から西暦2100年2100まで計算し、 否定する結果を得ている。
    • [372] 胡散臭い噂を検証するというこの記事の著者の態度は間違っていないのですが、 結果が信用できない qreki を検証の道具に採用してしまったのは致命的なミス。 たまたま検証結果に影響がなかったのは不幸中の幸いなだけであって。
  • [374] コメント欄では仏暦になることが多い日、少ない日を求めている。
    • [375] この結果には影響が出ていそう、傾向は大きく違わないでしょうけど。

• [366] AWK 版, JavaScript 版 (>>88), Visual Basic 版, Perl 版 (>>123), Perl 版 (>>15), PHP 版 (>>53), Python 版, Java 版を紹介。
• [367] AWK 版から西暦2224年2224の問題を、 Perl 版から旧暦2017年問題を紹介。
  • [368] しかし 「さあ、これらで六曜を把握してステキなプログラミングライフを送りましょう!」 と結んでいる。 わずか7年後に破綻すると理解しながら、 重視していなかったということか。

• [555] 「ponapalt Feb 21, 2011 243 たいむぼかん」

• [329] Re: カレンダー | 十進BASIC 第2掲示板 | 3482, しばっち, 投稿日:2014年 9月 2日(火)19時16分41秒, 2022-07-14T03:05:03.000Z https://6317.teacup.com/basic/bbs/3482

• [561] リンク先は AWK 版。しかしなぜか使われていない。

• [563] 「Pythonの実装が一番精度が高そうなので採用することに。」
• [564] 実行結果は書いていないので、何で判断したのか不明。

• [567] Swift で旧暦を得るにはこれという誤情報が流布されているようなので、 それに騙されたか?
• [568] NSCalendarIdentifierChinese の農暦が怪しいのはそうだけれど 農暦 、 それはここで指摘されている怪しさとは違います。

• [571] 旧暦2017年問題には言及なし
• [572] 旧暦2033年問題には言及なし

• [647] Microsoft Excel (VBA)
• [648] Ver 1.00, 2001/ 9/ 9
• [649] Ver 1.10, 2001/ 9/10
  • [661] 六曜算出関数 「ROKUYO」, 2022-12-08T11:09:00.000Z, 2002-02-09T05:00:52.957Z https://web.archive.org/web/20020209050010fw_/http://www.mars.dti.ne.jp/~ven02573/hatsu/nobuya5.htm
    • [662] 配布ファイル現存せず
• [645] Ver 2.00, 2003/ 9/21, 2022-12-08T10:56:43.200Z http://www1.plala.or.jp/chikada/vba/rokuyo/rokuyo.lzh
  • [646] この時点では解説ウェブサイトの VIsual Basic ソースコードを利用 (qreki とは無関係とみられる)
• [650] Ver 2.10, 2004/12/28
  • [652] 「2006年10月のバグを修正」
  • [653] 旧暦日付に関係する不具合か暦注計算のみ関係するものか不明
  • [660] 2022-12-08T11:05:37.00Z http://www1.plala.or.jp/chikada/vba/rokuyo/rokuyo200412.lzh
  • [656] エクセル六曜カレンダー旧暦月日表算出アドイン, 2022-12-08T11:03:35.000Z, 2011-03-03T18:01:52.736Z https://web.archive.org/web/20110303180059/http://www1.plala.or.jp/chikada/vba/rokuyo/rokuyo.htm
    • [657] 「海上保安庁 算出結果の検証に使用しました。二十四気節のデータが公開されています。」
    • [658] 「2004年12月 2006年10月の六曜が不正とのご指摘メールをいただき、修正しました。 過年度分にもバグがありそう・・・。」
• [651] Ver3.00, 2020/2/15
  • [654] この版から qreki の Visual Basic 移植版 (>>11) に切り替え
  • [655] AWK 版と JavaScript 版 (>>88) を参照
  • [659] 海上保安庁ページにリンクして検証に使用したという記述はこの版の前から変わっておらず、 この版で検証したのかは不明。

• [497] 正しい情報を見ていても、それを選ぶとは限らないのだなあ...

• [505] >>502 から派生したテストデータ。

• [498] go-qreki/qreki.go at master · shogo82148/go-qreki · GitHub, 2022-07-15T08:06:52.000Z https://github.com/shogo82148/go-qreki/blob/master/qreki.go
  • [499] qreki とは別手法の Go による実装。
  • [500] 名前の一致は偶然か、それとも参考にしたのか。
• [502] go-qreki/qreki_test.go at master · shogo82148/go-qreki · GitHub, 2022-07-15T08:08:25.000Z https://github.com/shogo82148/go-qreki/blob/master/qreki_test.go
  • [503] テストデータ。西暦2016年2016を中心に前後・閏月。 旧暦2033年問題は閏11月。旧暦2017年問題はぎりぎり範囲外。
• [501] 2016-03-26, 2016-03-27

• [252] >>54 のカレンダー。 こちらは JavaScript 版を使っている。
• [253] 「平成34年」になっていて古いまま。 本家 >>54 では令和に対応している。

• [621] 大学教授の高野氏に比定した根拠は不明。
• [663] 大学教授の高野氏は物理学者だが天文系ではない。 趣味的に手掛けた可能性はあるが、 それは他の (ウェブ検索で見つけられる範囲だけでも多数の) 同姓同名の高野氏にも言えることで、 同定するには相応の理由付けが必要。

• [643] 既存 Perl 移植版からの派生か独自移植版か不明