Javascriptを利用して、簡単に春分の日、秋分の日を計算する方法について、ＮＴＪ会長さんが掲示板に書き込んでくださった事柄について、関連するやりとりを、興味のある方のために「暦と天文の雑学」に掲載することにしました。

掲載にあたっては、掲示板で発言のあったＮＴＪ会長さん、角田さん及び私かわうそ＠暦の了解を得ております。

なお、掲示板上ではそれぞれのメールアドレスも記載が有りましたが、スパムメールの送り先として悪用されることが無いように、メールアドレスは削除致しました。

世界一単純かもしれない、春分／秋分計算ＮＴＪ会長 さん
　2004年7月15日(木) 18時12分

色々と考えていたのですが、相当に単純な方法で計算が可能かもしれないと気づいたので試して見ました。
手法的には、「基準年の春分点／秋分点通過から、地球公転周期で正１年後は、翌年の春分点／秋分点通過時ではないか？」という発想です。
手作業で行うなら大事の計算方法ですが、コンピュータではこのほうが単純になります。
JavaScriptのDate()は、内部的には1970年1月1日0時0分0秒（UTC）からの秒数（ミリ秒単位）なので、これを基準にしてみます。

new Date(公転周期[ミリ病]＊(西暦年－1970）＋1970年の春分点通過の基準からのミリ秒）
これだけで、目的年の春分通過の概算が得られる（はず）です。


実験的に３００年分の計算をさせてみました。

<STYLE>
.11,.19 {color:red}
.21 {color:pink}
.23 {color:aqua}
.24 {color:blue}
</STYLE>
<SCRIPT>
X=6829570000; //1970年の春分点通過時刻の年初からのミリ秒（推定概算）
Y=22935091700; //1970年の秋分点通過時刻の年初からのミリ秒（推定概算）
Z=31556926000; //地球公転周期のミリ秒（ミリ秒単位では不正確かも？）
document.write('<TABLE><TR><TH>基準から正１年後<TH>春分点通過<TH>秋分点通過');
for(i=0;i<300;i++){
document.write('<TR><TD><SPAN class='+new Date(Z*i).getMonth()+'>'+new Date(Z*i)+'</SPAN>');
document.write('<TD><SPAN class='+new Date(Z*i+X).getDate()+'>'+new Date(Z*i+X)+'</SPAN>');
document.write('<TD><SPAN class='+new Date(Z*i+Y).getDate()+'>'+new Date(Z*i+Y)+'</SPAN>');
document.write('<TD><SPAN class='+new Date(Z*(i+0.5)+X).getDate()+'>'+new Date(Z*(i+0.5)+X)+'</SPAN>');
}
document.write('</TABLE>');
</SCRIPT>

機知の範囲では、だいたい合ってるっぽいです。
問題は、３つの重要な定数の正確な値が解らないことです・・・
どなたか、手法に問題がないか、検証して頂けないでしょうか。。

RE:世界一単純かもしれない、春分／秋分計算 ＮＴＪ会長 さん
　2004年7月15日(木) 18時18分

あっと、300年チェックの４つめの日時は、春分から公転周期で半年後が秋分だとしたら？　という実験をした名残です。
見なかったことにしてください。。（すみません。）
RE:世界一単純かもしれない、春分／秋分計算 かわうそ＠暦さん
　2004年7月16日(金) 10時22分

NTJ会長様
書き込みありがとうございます。
考え方自体は、平均公転周期から求めるオーソドックスなものですので、大きな間違いはないと思います。
(計算結果の日付を CSSのclass定義して、色を変えるっていうのは、上手い手ですね）

ただ、現在の春分日・秋分日は視黄経0°、180°通過の日ですので、その間隔は365.24219日の前後に10分ほど変動することがあります。
現在のところ、秋分日が22,23の境近傍に来ることがあり、その場合上記の間隔の不等から日付がずれることがあります。
週末時間があれば、影響がないか確かめてみます。

考え方自体の話は、暦と天文の雑学の「将来の春分の日・秋分の日」に関連の解説記事がありますので、興味のある方はお読みください。
( http://koyomi.vis.ne.jp/reki_doc/doc_0330.htm )
RE:世界一単純かもしれない、春分／秋分計算 ＮＴＪ会長 さん
　2004年7月16日(金) 11時30分

> 考え方自体は、平均公転周期から求めるオーソドックスなものですので、大きな間違いはないと思います。
良かった、基本的には正しかったみたいですね。

> 考え方自体の話は、暦と天文の雑学の「将来の春分の日・秋分の日」に関連の解説記事がありますので、興味のある方はお読みください。
ここを見させていただいて、手法を考えついたんです。為になりました。（＾＾）

>ただ、現在の春分日・秋分日は視黄経0°、180°通過の日ですので、その間隔は365.24219日の前後に10分ほど変動することがあります。
>現在のところ、秋分日が22,23の境近傍に来ることがあり、その場合上記の間隔の不等から日付がずれることがあります。
そのようですねぇ。春分は、概算でそのまま適用できたのですが、秋分のほうは2012年に前日へズレてしまったので、10分ほど手前へずらしてお茶を濁しています。。
天文年鑑のバックナンバーを集めて、視黄経通過時刻の比較チェックを行って、適正な定数値を求めたいところです。

現在見かける春分／秋分の計算方法が、
『㈱恒星社厚生閣発行　暦計算研究会編　　『新こよみ便利帳』より』
のパターンばかりで、そっちの手法は手作業向きな計算方法で、
日時をマイクロセコンドで内部処理する日付型を使用したい場合には、
手法的にそぐわないような気がしまして。
マイクロセコンド単位で、基準年からの経過を単純計算で求めてしまって、
その結果をDate系クラスで変換してしまえば、一番単純なのではないかなぁ、と。（言語系にもよりますが。）

>週末時間があれば、影響がないか確かめてみます。
ありがとうございます。よろしくお願いしますです。

RE:世界一短いソースかもしれない、オートカレンダー ＮＴＪ会長 さん
　2004年7月16日(金) 11時33分

>(計算結果の日付を CSSのclass定義して、色を変えるっていうのは、上手い手ですね）
あ（＾＾； コレは実は手抜きです。（汗
ただ、コレを利用してオートカレンダーを作る場合には、.Day() の結果をclass定義へつなげると、曜日カラー指定が簡単になって便利なので、よく使ってます。
ただ、そのまんまだと数字だけなので、弊害が有りそうなので、プレフィックスを挿入するほうが良さそうですね。

<STYLE>
SPAN {width:20;text-align:right;}
.W0,.W6 {color:red}
</STYLE>
<SCRIPT>
for(i=0;i<new Date((new Date()).getYear(),(new Date()).getMonth(),1).getDay();i++)
document.write('<SPAN></SPAN>');
for(
i=new Date((new Date()).getYear(),(new Date()).getMonth(),1);
i.getMonth()==(new Date()).getMonth();
i.setDate(i.getDate()+1))
document.write((i.getDay()?'':'<BR>')+'<SPAN class="W'+i.getDay()+'">'+i.getDate()+'</SPAN>');
</SCRIPT>

こんな具合だと、Class指定が混乱しないので良いのではないかと。
（無茶苦茶乱暴なスクリプトですみません（＾＾；）

当面ですが、比較の結果 かわうそ＠暦 さん
　2004年7月17日(土) 17時36分

手元にすぐに用意できた暦が2100年までしかなかったのですが、その間に関しては一致しているようでした。
また、先の分まで作ったら比較してみます。
JavaScript、恐るべし・・・ ＮＴＪ会長 さん
　2004年7月21日(水) 11時8分

自分では、結構なJavaScript使いのつもりだったのですが、ちょっと驚いたことができてしましました・・・
上記の、300年分検証で、初期値をマイナスにしてみてください。
キッチリ、想定どおりに動いてしまうようです。
原点こそ1970年ですが、マイナスまで処理できてしまうとは・・・。

それと・・・
http://www.asahi-net.or.jp/~CI5M-NMR/misc/equinox.html
こちらのサイトで確認したところ、暦計算研究会編『新こよみ便利帳 ver.1.2』 の算式では、1900～1970年通用の部分が合わないそうです。
定数、1983を1980に変更すると直るとのこと。
ここの「春分日・秋分日の計算フォーム」でも、ずれている模様です。

ちなみにあたしのロジックでは、1927年が、9分12秒ほど合いませんでした。
定数X（春分点通過）をその分減算すべきなのか、定数Z（公転周期ミリ秒）が正しくないのか・・・
こよみ便利帳の式について かわうそ＠暦 さん
　2004年7月21日(水) 14時58分

>暦計算研究会編『新こよみ便利帳 ver.1.2』 の算式では、
>1900～1970年通用の部分が合わないそうです

1850-1980年までの式になぜか -1983 と言う数字が出ておりますが、あれは -1980 の誤りだと思います。
最初はあのままの式を使っていましたが、いつだったか気が付いて直しておりますので、「春分日・秋分日の計算フォーム」も多分直っているはずです。
先ほど、そのあたりの式の入ったJavascriptファイルを見てみましたが、直ってましたので、大丈夫です。
もしかして、プロキシあたりに、古いJavascriptファイルがキャッシュで残っているのかも。どないでしょう？
RE:こよみ便利帳の式について 角田
さん
　2004年7月21日(水) 17時10分
HomePage
ご無沙汰です♪
>>1900～1970年通用の部分が合わないそうです
>1850-1980年までの式になぜか -1983 と言う数字が出ておりますが、
>あれは -1980 の誤りだと思います
その件は私もおかしいと思って、以前、海上保安庁の担当者に問い合わ
せて確認した事があります。結論は「間違いではない」という事です。
簡単に言えば、計算に使った言語仕様の違いによるものです。
以前は、科学計算といえばFortranが全盛だった事を考えれば、
それに則した式になっているという事で納得できると思います。
↓下記参照
http://www.h3.dion.ne.jp/~sakatsu/holiday_topic.htm#syunbun
RE:こよみ便利帳の式について かわうそ＠暦 さん
　2004年7月21日(水) 17時46分

なるほど。Fortran のデータ型変換関数 INT() を使ったわけだ。
確かにそうなら納得できます。
ただ、あの箇所の計算記号の説明で
「[]はガウス記号で」
と言うのが誤解を生む元ですね。その後に、「小数部を切り捨てた」と書いてあるので、なるほど Fortran の INT() だとなりますが、ガウス記号なら、
　n = [k]
の、nは、kを超えない最大の整数って意味であって、小数部を切り捨てるって意味じゃないですよね。

でも一つ謎が解けました。
RE:こよみ便利帳の式について 角田
さん
　2004年7月21日(水) 17時33分
HomePage
当時のメールが残っていたので参考にアップしときます。
http://www.h3.dion.ne.jp/~sakatsu/holiday_gauss.txt

この後に、ＮＴＪ会長さんによる、この計算結果と実際の春分の日・秋分の日の比較結果が有りましたが、数字の長い並びで読みにくいということから、御当人の希望により、削除致しました。

初稿掲載 2004.07.27