【マイレース開発記録(5)】ユリウス日との格闘　　　　　　　　　　　　　　　　　　　　　　　

天体計算の前にある“時間”という壁

Swiss Ephemeris を導入し、
UTC変換の重要性に気づいた私は、

「これで計算は安定するはず」

と思っていました。

しかし、まだ何かがずれている。

微妙に違う。
誤差がある。

ここで私は、
ユリウス日そのものを理解していないことに気づきました。

ユリウス日とは何か

ユリウス日（Julian Day）とは、

紀元前4713年1月1日正午を起点とした通算日数

という特殊な時間表現です。

しかも重要なのは、

1日は「正午」から始まる

という点。

普通のカレンダーは0時スタートですが、
ユリウス日は12時スタート。

ここを理解していないと、
理論的に0.5日のズレが発生します。

なぜ正午スタートなのか

最初は違和感しかありませんでした。

なぜ0時じゃないのか。

調べていくと、理由は天文学的でした。

• 観測は夜に行われる
• 日付変更をまたぐと計算が面倒
• 正午基準の方が都合が良い

つまりこれは、

人間の生活時間ではなく、観測の都合

で作られた時間体系なのです。

ここで私は理解しました。

ソフトウェアの「時間」は、
人間の感覚とは必ずしも一致しない。

hourは「小数」で渡す

Swiss Ephemerisの swe.julday() は、

Python

swe.julday(year, month, day, hour)

という形を取ります。

ここでいう hour は、

• 13時30分なら → 13.5
• 13時15分なら → 13.25

のように、小数で渡します。

私は最初、

• hourだけ渡していた
• minuteを無視していた
• 秒を考慮していなかった

つまり、

時間を丸めていた。

これが微妙な誤差の原因でした。

実装の修正

修正後のコードはこうです。

Python

utc = dt.astimezone(timezone.utc)
hour = utc.hour + utc.minute / 60 + utc.second / 3600
jd = swe.julday(utc.year, utc.month, utc.day, hour)

この形にして初めて、

• 日付
• 時間
• タイムゾーン

が正しく整合しました。

ここまで来てようやく、

天体位置が安定して再現可能になりました。

0.5日のズレ事件

一度、計算結果がどうしても合わない日がありました。

何度検証しても微妙に違う。

原因は、

正午基準を理解していなかったこと

でした。

例えば、

• 0:00 JST → 前日15:00 UTC
• さらにユリウス日が正午基準

ここが絡むと、
直感で考えると混乱します。

私はAIに質問を投げながら、

• どの時点でUTC変換される？
• juldayの基準は？
• 小数時間の扱いは？

と、順番に整理していきました。

結果、

計算ロジックよりも「時間概念の理解不足」が原因

だったと分かりました。

実務的に得た学び

今回のユリウス日との格闘で学んだことは明確です。

1. 時間は必ず基準を確認する
2. タイムゾーンは曖昧にしない
3. 浮動小数点の扱いを軽視しない
4. 「動いている」＝「正しい」とは限らない

これは占星術に限らず、

• ログ解析
• 分散システム
• API連携
• データ同期

あらゆる実務で重要な考え方です。

発達特性との向き合い方

私は細部に意識が向きやすい反面、

• 全体基準を見落とす
• 前提を飛ばしてしまう

という傾向があります。

ユリウス日の問題もまさにそれでした。

しかし今回は、

AIとの対話を通じて、

• 「基準は何？」
• 「前提は？」
• 「この値は何単位？」

と問い続けることができました。

以前なら混乱して投げていたかもしれません。

今回は違いました。

理解するまで分解する。

それをやりきれたことが、
このプロジェクトの大きな意味の一つです。

次回予告

時間の扱いが安定したことで、
ようやく私は“周期”を実装できるようになりました。

しかしそこでもまた、

• 周期の定義
• 正規化
• フェーズの扱い

で試行錯誤することになります。

次の記事では、

【マイレース開発記録(6)】phase設計の試行錯誤

を書いていきます。