アカウント名:
パスワード:
天保暦まで実装したら公開すればいい
その場合天保15年(1844年)以降のみ対応で公開するの? 先発天保暦にするの?太陰太陽暦は新しい暦法ほど正確な代わりに複雑な計算が必要になっているから、天保暦が実装できたらそれ以前の暦法の実装は容易だと思うけど
太陰太陽暦は新しい暦法ほど正確な代わりに複雑な計算が必要になっているから、天保暦が実装できたらそれ以前の暦法の実装は容易だと思うけど
過去の日付の個数は有限なので、たとえば「1970年1月1日から32767日前は、和暦でx年y月z日」と列記されたテーブルを作り上げてしまえば良いのではないでしょうか?
2000年分でも約73万件。一度作り上げてしまえれば、コンピュータの処理能力からみて、大したものでもないかと。
(暦の変遷の調査や検証の労力は考えてない)
それでも全然いいと思いますよ。多分、毎日のテーブルは必要なくて毎月初分だけあればいいはずなので、閏月などを考えれば 2000 年で約25,000件でよいはず。その手のことをやっているのは、国立天文台の日本の暦日データベース (※) などいろいろあるのですが、Webでの検索サービスはあっても、データベース自体は公開されてないっぽい。フリーで使えるデータベースがあるといいなと思います。
そういうデータベースを独自に作るにしても、手作業で 25,000件を作るより、暦法を算出する実装を作ってそれを使って作った方が楽だろうとは思いますが。
(※) https://eco.mtk.nao.ac.jp/cgi-bin/koyomi/caldb.cgi [nao.ac.jp]
個別の文献からの逆算の方が面倒かなぁ、と思った天保17年があったり、閏月をスッ飛ばしてたり、でもそのへんは干支からフィードバックできたりと
2000年分でも約73万件。
Excelの出番だな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
とりあえず (スコア:0)
天保暦まで実装したら公開すればいい
Re: (スコア:0)
その場合天保15年(1844年)以降のみ対応で公開するの? 先発天保暦にするの?
太陰太陽暦は新しい暦法ほど正確な代わりに複雑な計算が必要になっているから、天保暦が実装できたらそれ以前の暦法の実装は容易だと思うけど
Re:とりあえず (スコア:2)
太陰太陽暦は新しい暦法ほど正確な代わりに複雑な計算が必要になっているから、天保暦が実装できたらそれ以前の暦法の実装は容易だと思うけど
過去の日付の個数は有限なので、たとえば「1970年1月1日から32767日前は、和暦でx年y月z日」と列記されたテーブルを作り上げてしまえば良いのではないでしょうか?
2000年分でも約73万件。一度作り上げてしまえれば、コンピュータの処理能力からみて、大したものでもないかと。
(暦の変遷の調査や検証の労力は考えてない)
Re: (スコア:0)
それでも全然いいと思いますよ。
多分、毎日のテーブルは必要なくて毎月初分だけあればいいはずなので、閏月などを考えれば 2000 年で約25,000件でよいはず。
その手のことをやっているのは、国立天文台の日本の暦日データベース (※) などいろいろあるのですが、Webでの検索サービスはあっても、データベース自体は公開されてないっぽい。
フリーで使えるデータベースがあるといいなと思います。
そういうデータベースを独自に作るにしても、手作業で 25,000件を作るより、暦法を算出する実装を作ってそれを使って作った方が楽だろうとは思いますが。
(※) https://eco.mtk.nao.ac.jp/cgi-bin/koyomi/caldb.cgi [nao.ac.jp]
Re: (スコア:0)
個別の文献からの逆算の方が面倒かなぁ、と思った
天保17年があったり、閏月をスッ飛ばしてたり、でもそのへんは干支からフィードバックできたりと
Re: (スコア:0)
Excelの出番だな。