Ephemeris uncertainty
A natal chart chains several approximations: orbital theory, coordinate transforms, house algorithms, clock/time-zone input, and birth-time recording error. Treating the output as exact to the arcminute is usually unwarranted.
Layers of error
| Layer | Typical impact on natal charts |
|---|---|
| VSOP87 + local Moon model | Sun/planets: usually ≪ 1° for sign work; Moon may differ more from JPL/Swiss |
| Geocentric vs topocentric | Planets: small; Moon: up to ~arcminutes (geocentric-vs-topocentric) |
| UT vs TT | Sub-arcminute for modern dates; negligible vs birth-time error |
| House system math | Algorithm-specific; extreme latitudes stress Placidus |
| Birth instant | Often dominant for ASC/MC (birth-time-accuracy) |
| Time zone / DST mistake | Can shift angles by hours |
What is “good enough”?
- Sign placement (Sun through Pluto, nodes) — VSOP-class geocentric longitudes are routinely adequate when the instant is correct.
- Moon degree within sign — verify against a reference ephemeris if you need arcminute lunar aspects.
- Angles and Placidus houses — require accurate UTC + coordinates; test sensitivity with ±4 minute shifts.
AstroRust testing stance
astrorust_ephemerides integration tests document fixture tolerances tied to this implementation, explicitly not Swiss Ephemeris or JPL DE. Use them to catch regressions, not to certify arcsecond agreement with every almanac.
For highest-precision work (eclipses, exact aspects to angles), compare against a DE-based almanac or Swiss Ephemeris outside this stack.
References
- Ephemeris — Wikipedia
- VSOP model — quoted accuracy ranges
See also vsop87, julian-day-ephemeris, data-quality.