和暦を正しく扱うための和暦ライブラリ 53
ストーリー by nagazou
混乱 部門より
混乱 部門より
なぎせさんが「和暦を正しく扱うための暦の話」という記事を作成している。この記事は、日本では明治6年(1873)よりグレゴリオ暦が採用されているが、それ以前の年代での和暦の扱いについて注意点をまとめたものとなっている。和暦をコンピューター上で扱う場合の問題点などに関しても触れられており、コンピュータ上での扱いはISO準拠（ISO 8601）が無難としつつも、表示上は利用者の文化にあわせて表示する必要があるといったことなどが紹介されている。このほか、ユリウス暦とグレゴリオ暦の切り替わりで生じる問題点など、暦をコンピューター上で扱う上での注意点などがまとめられている。なお同氏はこの問題に対処するための和暦ライブラリも製作中だという（和暦を正しく扱うための暦の話）。
西暦1900年問題 (スコア:2)
> 日本では明治6年(1873)よりグレゴリオ暦が採用されている
しかし、当初実装にバグがあり、明治31年(西暦1898年)に慌てて閏年のルールを変更している。
明治三十一年勅令第九十号（閏年ニ関スル件）https://elaws.e-gov.go.jp/document?lawid=131IO0000000090 [e-gov.go.jp]
マクロの基本は検索置換(by y.mikome)
Re: (スコア:0)
ぶっちゃけ文献当時に記された歴って伝達に数日どころか月単位でかかる頃の日付情報なんで
年単位でずれてない限りは大した差にはならんのよね
唯一ずれてなさそうなのは時代を問わず本営発表の大本の日付くらいじゃないかな
# 端的に言うと「こまけぇことは(ry」
てっきり…… (スコア:2)
旧暦マニアの知人が、ここ1〜2週間ほどtwitterに「初日の出を見に行ってきます」「そろそろ鏡開きですね」とか投稿してたんで「太陽暦の日付けを旧暦に変換する」みたいなライブラリか、面白そうだけど、使うのは日本全国でも当該知人ぐらいしか居ねえよなとか、一瞬、思ってしまった
Re: (スコア:0)
六曜(仏滅、大安など)もそれで決まるので結構需要あるんじゃないすかね
とりあえず (スコア:0)
天保暦まで実装したら公開すればいい
Re: (スコア:0)
その場合天保15年(1844年)以降のみ対応で公開するの? 先発天保暦にするの?
太陰太陽暦は新しい暦法ほど正確な代わりに複雑な計算が必要になっているから、天保暦が実装できたらそれ以前の暦法の実装は容易だと思うけど
Re:とりあえず (スコア:4, 興味深い)
親コメントの「天保暦まで実装」は「元嘉暦から天保暦までを実装」という意味だと思う。
また、「新しい暦法ほど複雑な計算なので、それが出来たらそれ以前の暦法の実装は容易」とは一概に言えない。
寛政暦や天保暦だと三角関数を用いて計算していて、暦法に書いているとおりに式を組み立てれば実装出来るところを、
それ以前の暦だと三角関数を用いていない代わりに数表からの表引きを使っていて、この数表がどうやって出来上がったものなのかがわからないので、ひたすら暦法に書いてあるとおりにテーブルを作っていかなければいけないのだが、
・ 暦法が、宋書・唐書などの史書に転載される際、数表は省略されがち。数表を探し求めるところから作業が始まる（見つかるとは限らない）。
・ 前後の連続性や表内の整合性（これとこれとを足したらこれになるはず、等）を考えたとき、異常値がときどき混じる。
これが、暦法が作られた当時からのもので、その暦が実用されていた当時から、異常値をもとに作暦していたのか、
当時は正しい値だったのだが、後世の書写の際に誤ったものなのかがわからない。
実際の作暦と突き合わせて、どちらで計算した方が作暦と合うかを見るなどして、数表の校訂をしていかないといけない。
などがあってかなり面倒。寛政暦とか天保暦の方がはるかに楽。
また、天保暦の計算はフーリエ展開したような感じの式で、振幅・周期・位相が異なる三角関数を足し合わせていくだけなので、式が単純。
寛政暦は、力学的計算（の近似計算）をガリガリやっていく式で、式の意味を理解するのに一苦労する。
天保暦は定気法で寛政暦は平気法だから、中気を求める際に太陽黄経の運行遅速を求める必要がない分、寛政暦の方が楽なんじゃないかと思うかも知れないが、定朔を求める時に月黄経の運行遅速だけでなく太陽黄経の運行遅速が必要なので、実装上、楽になるわけではない。
結局、実装するなら天保暦が一番楽。
Re: (スコア:0)
「天保暦が一番楽」は言い過ぎかな。
平朔平気の元嘉暦はマジで簡単。カレンダーを作れればいいレベルであれば、数行で計算方法を説明できる。
Re:とりあえず (スコア:1)
そうなんだよな、カレンダーを作れればいいレベルまでなら簡単。
そのレベルを越えて、実際に使われた暦の再現は、結局、実際の暦に当たらないといけないからやっかい。
(計算結果の縁起が悪かったら朔を1日ずらすとかしてるから、実際の暦は計算結果からズレてるんだよな、あちこち。
たとえば、朔旦冬至をでっちあげるとか。)
Re: (スコア:0)
実際に使われた暦にずれがある可能性があるのはどの暦も一緒で天保暦以外が特に不利な理由はないのでは?
Re: (スコア:0)
ていうか例外処理の実装なんて例外テーブルを用意するしかないから、実装する観点からはむしろ一番簡単(表データの用意を除けば)。結局基本の計算式の複雑さが実装の難易度を左右すると思うんだけど。
Re: (スコア:0)
元号制（始まりは645年頃とされる大化元年）の前から使われてきた「干支」制の方が実装は楽なんじゃ？（元号中断期がある様な時代ではほぼ公式に使われてた筈）
Re: (スコア:0)
むしろ干支のほうが普段遣いでは多かった。(一世一元になるまでは)数年～長くても十数年で、しかも不定期に改元される元号よりも干支のほうが楽に決まってる。それでも太陰太陽暦の計算は避けて通れないが。
Re: (スコア:0)
それ以外にも、地域によって同じ暦でも日付が違っているとか。
暦の発行元によって違うとか。
色々あったような。
Re: (スコア:0)
不定時法の天保暦が一番楽はさすがに言い過ぎ
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の出番だな。
Re: (スコア:0)
スライドの最終ページ、コード中ふんだんに漢字が使われてるな。
単語区切りの命名規約に悩みそう。
Re: (スコア:0)
原文が漢文で書いてあるんで、変数名とかどうしても漢字になっちゃうんじゃないかな。
alphanumeric で書こうにも、英語にどう訳していいのかわからない、普段使う言葉ではないのでローマ字で書いても見たとき意味がわからない、なんだったらそもそもどう読めばいいのかもわからない。
原文に書いてあるとおり、漢字で書くしかない。
URL.... (スコア:0)
タイトルのカナはそのまま、漢字部分は無理矢理ピンインで読んでるんでしょうか。
和暦よりもそっちが気になりました。
Re:URL.... (スコア:1)
speakerdeckの仕様です。
Re:URL.... (スコア:1)
タイトルを自動的にURLにしてくれるようなCMSだとそんな感じ。
頑張って作っていると思うが (スコア:0)
法的な文書や契約書、役所や企業の文書などから和暦をなくして欲しい。
新年だけは和暦で祝いましょう。
# 同じ年に和暦が複数回変わるとかありえるのだろうか？
# 実際に起きれば発狂する人が出てきそうだ
Re:頑張って作っていると思うが (スコア:2)
グレゴリオ暦は、1月1日がなぜその日なのか必然性がないから美しくない。
和暦の正月1日は、「冬至と春分の中間（立春）に一番近い朔日」なので科学的で美しい。
今からでも平気法の太陽太陰暦に改暦すべき。
Re:頑張って作っていると思うが (スコア:1)
平気法って、1年を時間で24等分する雑な定義だから、暦の上の春分は実際の春分と一致しないんだぜ。
（2日ぐらいずれる）
じゃあ春分が正確な定気法にする？
こっちは角度で分割するせいで、節気の日数が一定じゃないから、閏月の計算がすごい面倒。
しかも、地球の近日点はおよそ21,000年で一周するから、1,000年前だと17日ぐらい手前になる。
そもそも、地球の自転・公転周期、月の公転周期だって、本当は一定じゃない。
公転軌道は、厳密にいえば楕円じゃない。
空間は、重力によって歪んでいるから平坦じゃない。
どだい、惑星の運行なんざ、人間の美醜感覚に合わせちゃくれないのさ。
だから、適当でいいんだよ、適当で。
Re: (スコア:0)
中国人が正確な暦を求めた理由は、日食月食の発生と皇帝の徳が関連付けられていたので予想を外すとヤバいという理由によるものだから、現代においてそこまでややこしいことする理由ないよな
Re: (スコア:0)
いや、今からでも、春分の月が第1の月となるロムルス暦に改暦すべき。
Re: (スコア:0)
月が割り当てられていない冬の期間はみんなでお休みだ
Re:頑張って作っていると思うが (スコア:1)
＞ 同じ年に和暦が複数回変わるとかありえるのだろうか？
749年 天平 天平感宝(5/4～) 天平勝宝(8/19～)
Re: (スコア:0)
今だにウチの母親は「昭和だと今年何年だっけ？」とかいってくるのでマジ勘弁ですわ。
# > # 同じ年に和暦が複数回変わるとかありえるのだろうか？
# 実はあったのかもしれないけど、途中の奴は面倒だから記録に残すのやーめた、ってことで
# 無かったことにされてたりして
# 元年って何日から？って結構いろいろなのね（近代）
Re:頑張って作っていると思うが (スコア:1)
大正だと今年何年だったっけ？はごく偶にやるなぁ。
正確には民國紀元だけど。台湾土産の賞味期限で
Re: (スコア:0)
でも数字4桁よりも元号と数字ひとつか二つの方が分かりやすいからなぁ
そういう人も無視できない数いるから残ってるわけで
Re: (スコア:0)
西暦下二桁でいいじゃん
そして2100年問題が(笑)
Re: (スコア:0)
そろそろ昭和100年問題が近づいているが。
Re: (スコア:0)
そういう人は西暦も下2桁しか使わないので
Re: (スコア:0)
もしかしてお母さまは、帝都物語か勇者特急マイトガインといった、
「昭和が百年くらい/百年以上続いてる世界」から異世界転生なさった方なのでは?
Re: (スコア:0)
法的には旧暦はとっくに廃止されているのに民間がいつまでも使ってるんだよ
Re: (スコア:0)
自分が住んでいる市は、火葬場が休みの日を毎年度公表している。
一見ランダムに見えるが、なぜか毎年、偶然にも1月1日と友引の日になっている。
日常的暗算の鈍臭い！ (スコア:0)
知人の一人にこの手の暗算の猛者が居るんだが！
ICUのクソ和暦対応を改善してくれ (スコア:0)
オレオレ日本語化はもうたくさん。調査研究のコストを回収するために法人向けの商用ライブラリにするなら仕方ないが
令和の改元の時から思ってるんだけど (スコア:0)
IPA辺りの国の機関主導で西暦・和暦変換ライブラリ提供してくれないかなあ？
Web系でもPCでもスマホでも
それこそメインフレーム用とかVB6用とか考えられる殆どのプラットフォームに
提供してほしいなって。
Re: (スコア:0)
ちゅうても学術用途でも無けりゃ明治以降の年号で十分だし、
その範囲なら、まだ公式のライブラリが必要なほどややこしい話でもないだろう
それにOSとか実行環境とかでも年号対応してるし、国がわざわざやることなんてあるかなぁ
2033年問題 (スコア:0)
どう対応するか見解統一されたのかな？
まあ昭和100年問題の方が近いしなんかありそうだけど
Re:2033年問題 (スコア:1)
日本暦学会会長、国立天文台暦計算室長、全国カレンダー出版協同組合連合会特別理事などを役員とする「日本カレンダー暦文化振興協会」が、
2015年8月に「2033年旧暦閏月問題の見解」を発表し、2033年の置閏について「複数ある閏月候補の内、閏11月を推奨する」との結論を出している。
発表後、異論らしい異論は出ていない。
事実上、見解統一されたと思ってよいと思う。
Re: (スコア:0)
おお、解決してたのか。助かる。
六曜を気にする業界向けに計算しないといけないケースがあって面倒なんだよな…。
結婚式場の予約システムで大安がズレてるとか言われて慌てたことがある。数年前の3月で、希にある罠だったっぽい。
太陽太陰暦は複雑なので廃止されて当然だけども、未だ残ってるのが厄介だよね。
いっそヒジュラ暦みたいに太陰暦なら楽なのに…ｗ
※でもヒジュラ暦も29日/30日の調整が統一されてなかったり面倒くさいね。
…ここはユリウス日で統一すべきか…
かなり特殊なシステムだけだよね (スコア:0)
明治一桁以前の和暦が必要になるのなんて
Re: (スコア:0)
年金記録データとか？
#変換エラーでて見たら元号「G」あってキレた
Re: (スコア:0)
iOSのクソ元号サポート [apple.srad.jp]を置き換えたいというのが一番の需要だと思う。明治5年以前をサポートする必要なんかないのに