Most "what is my Chiron sign" tools need a server, or lean on a library that has no support for minor bodies. I wanted one that runs entirely in the browser, with nothing sent anywhere, and that I could check against real data. Here is how I built it, and the one bug that cost me an afternoon.
The result is a set of free calculators at zodiaccalculators.com: Venus, Saturn return, North Node, Chiron, Juno and Black Moon Lilith.
Planets are easy, minor bodies are not
For Venus and Saturn I used Astronomy Engine (MIT licence). It gives geocentric positions in the browser with a small footprint. I take the apparent position, convert to ecliptic longitude of date (the tropical zodiac that Western astrology uses), and divide by 30 to get the sign.
Chiron and Juno are different. Astronomy Engine does not include them, and shipping a full ephemeris file to every visitor is not realistic. The data comes from NASA/JPL Horizons, which publishes orbit files for individual small bodies.
Pre-computing a table instead of shipping an ephemeris
I did the heavy work once, offline, in Python:
- Download the SPK orbit files for Chiron and Juno from Horizons.
- With Skyfield and the DE440s planetary ephemeris, compute the apparent ecliptic longitude of date for every day from 1900 to 2099, at noon UT.
- Store each longitude as a 16-bit integer in units of 0.01 degree.
- Base64-encode the whole array into a JavaScript file.
That is 73,049 values, about 190 KB per body after base64. In the browser, a lookup is a base64 decode, then linear interpolation between two daily values. Because these bodies move slowly, I measured the interpolation error against the exact calculation and it stayed below 0.006 degrees. A sign is 30 degrees wide, so that is irrelevant for anything but the last minutes before a sign change.
The sign-change problem
If someone was born on a day when the body crossed from one sign into the next, the right answer depends on the time and the time zone. The tool does not guess. It scans every hour across the longest possible span of that calendar date (from UTC+14 to UTC-12) and, if more than one sign appears, shows both and asks for a birth time and offset.
The lunar nodes, and the bug
Black Moon Lilith and the mean node come from the polynomial formulas in Jean Meeus, Astronomical Algorithms. The true node is the osculating node of the Moon's orbit, which I calculate from the Moon's geocentric state vector.
This is where I lost the afternoon. My results were consistently off by 0.33 to 0.38 degrees for dates in the 2020s, and the error grew steadily over the decades. I had added a precession correction, and it turned out the coordinate frame I was already using had precession accounted for. I was applying it twice. Removing the extra term brought the values in line with published ingress tables, down to the day. A growing, linear error over time is a good sign that you have double-counted something time-dependent.
How I checked it
- Venus and Saturn against NASA JPL's DE440 ephemeris at a spread of dates.
- Chiron against Skyfield with the same orbit file, and against published sign-ingress tables.
- The mean and true node against published ingress tables.
- Juno through the same pipeline as Chiron, plus an orbital-element check. I could not find an independent published table for it, so that is the weakest validation of the set, and I say so on the site.
What I would do differently
I would have started with the independent check. Writing a comparison against a published table first would have shown the precession error in minutes instead of hours.
Try it
If you are curious what your own placement looks like, the Chiron calculator and North Node calculator both run fully client-side, and the position data is just a static file you can inspect in your browser's network tab.
The astronomy is a calculation. The meanings attached to it are astrological tradition, not science, and the site says so.
Top comments (0)