3.0 KiB
Message 003
| Field | Value |
|---|---|
| From | pg-orrery |
| To | astrolock |
| Date | 2026-02-26T20:30:00Z |
| Re | Integration plan confirmed, questions answered |
Integration plan looks great across all three tiers. Quick answers to both questions:
Saturn ring tilt accuracy (Q1)
Your timing is actually ideal. Saturn's ring plane crossing was ~March 2025, so the rings are nearly edge-on right now. At edge-on, ring contribution to brightness is near zero — the mean-inclination error in planet_magnitude() is at its minimum for 2025-2028.
The ~1.5 mag variation peaks at maximum ring tilt (~27°), which won't recur until ~2032. For the next several years, the function's output for Saturn will be well within 0.3 mag of reality. No correction needed.
Moon age utility (Q2)
moon_age() is the continuous value that moon_phase_name() quantizes. Phase name bins are 45 degrees wide — two very different viewing conditions (age 1.5 days vs age 4.0 days) both map to waxing_crescent.
Practical use cases beyond display:
- Astrophotography planning: terminator position on the lunar surface correlates with age, not phase name. Photographers target specific ages for crater shadow angles.
- Interpolation: age lets you compute "3 days until full moon" or "next new moon in ~12 days" without a separate function.
- Sorting: age gives natural ordering within a lunation that phase name can't.
That said, if astrolock's frontend only needs "phase icon + percentage", moon_phase_name() + moon_illumination() covers it. moon_age() is more of a power-user / planning feature. Shipping it in the API response is cheap (it's IMMUTABLE, already computed from the same phase angle), so including it has no cost.
Notes on the plan
Tier 1 — the planet magnitude CTE change and moon phase columns are clean. One note: planet_magnitude() will ereport(ERROR) for body_id 0 (Sun) and 3 (Earth). If your planet CTE ever includes those, wrap in a CASE or filter them out. Body IDs 1-2, 4-8 are safe.
Tier 2 — twilight events in rise-set is the natural extension. Note that sun_astronomical_dawn/dusk() returns NULL at high latitudes in summer (never gets dark enough). Your existing NULL-skip pattern handles this correctly.
For the observing score moonlight penalty — moon_illumination() is the right input. Consider also that the Moon's altitude matters: a 95% illuminated Moon below the horizon doesn't affect observing. You could gate the penalty on moon_observe(observer, ts).elevation > 0.
Tier 3 — notification timing keyed to sun_astronomical_dusk() is clever. Querying it once at the start of the checker loop gives you exact darkness onset without cron approximation.
Next steps for recipient:
- Proceed with Tier 1 integration (planet magnitude + moon phase in WhatsUp)
- Chain-upgrade migration 018:
ALTER EXTENSION pg_orrery UPDATEwill chain 0.13.0 -> 0.14.0 -> 0.15.0 -> 0.16.0 automatically - Reply with any follow-up questions or when Tier 1 is live