How we calculate your chart.

Here is what a chart on zodiacs.org claims, how each part is calculated, and where its precision has honest limits.

The ephemeris

Planetary positions come from Astronomy Engine, an open-source library built on the VSOP87 planetary series and the NOVAS reduction, with a custom integrator for Pluto, which VSOP87 does not cover. Its Moon comes from the Nautical Almanac Office's Improved Lunar Ephemeris, which descends from E. W. Brown's theory. It is designed to stay within one arcminute of NOVAS — that is the library's own target, not a measurement of this site, and what we measured is in the next section.

We compute apparent geocentric tropical longitudes of date, the standard frame of Western astrology. For the planets that means light-time and aberration are both applied, and nutation is applied to everything. The Moon is the exception, and it is worth naming rather than glossing: its position comes through the geocentric lunar vector, rotated by the engine into the true ecliptic of date with full IAU 2000B nutation but neither light-time nor aberration. The whole of the Moon's disagreement with Swiss Ephemeris, which does apply both, is at most 7.6 arcseconds over the span measured below, with a median of 0.9 — so the omission costs no more than that, rather than adding a separate error on top of it. The lunar node is the true node, derived from the Moon's instantaneous orbit.

Every change to the engine runs an automated accuracy test: positions are compared against NASA JPL Horizons reference data at two dates, 1907 and 2020, with tolerances of 0.05° for the Sun and planets and 0.15° to 0.2° for the Moon. The test suite also checks the sky against itself, with the tolerance each check actually deserves: at solar culmination the computed midheaven sits within 0.2° of the Sun's longitude, and at sunrise the ascendant within 2.5° — looser because sunrise is when the Sun's upper limb clears a refracted horizon, which is a different instant from the one the ecliptic ascendant marks.

Agreement with Swiss Ephemeris

On 20 September 2026 we measured this engine against Swiss Ephemeris 2.10.03 reading its own JPL-derived data files: 18 charts × 10 bodies, on dates written down before any number was taken and picked to include the awkward ones — 1801, the poles, sign boundaries, an unknown birth time. Both sides were put in the same frame, checked by switching each effect off and watching the difference move rather than by assuming it matched. On 25 September, when the engine's clock changed (below), we measured it again; the figures here are that run's.

Across the 160 measurements from 1801 to 2026, the median disagreement in longitude is 1.6 arcseconds, the 95th percentile is 12.1 arcseconds, and the largest is 18.6 arcseconds — Pluto in 1801. Dates picked in advance can miss a body's worst moments, so we also compared every tenth day from 1800 to 2199, at noon UTC, for the ten bodies and the North Node. Up to 2026 that is 91,201 comparisons, with a median of 2.0 arcseconds and a largest of 22.9 arcseconds — Venus in 1878. A zodiac sign is 30 degrees, which is 108,000 arcseconds, so a difference that size changes a sign only for a body within 23 arcseconds of its edge.

The other 20 measurements are the far-future cases, and none of them reaches one arcminute: the largest is 24.8 arcseconds, Pluto at 2190, where the two ephemerides differ. For the Moon the clock matters more. ΔT, the gap between uniform atomic time and the Earth's slowing rotation, is observed only up to the present, and past it both programs extrapolate. From 2100 to 2199 their values differ by 14.3 to 36.7 seconds, inside this engine's own one-sigma uncertainty, which grows from 42.4 to 103.4 seconds over those years. The Moon moves about half an arcsecond per second of time, so the difference alone moves it by 7.0 to 23.4 arcseconds. The every-tenth-day comparison shows the same: at the same instant of Terrestrial Time, which takes the clock out, the Moon stays within 7.2 arcseconds from 2150 to 2199, and at the same UT within 20.5 arcseconds.

Up to the present the engine uses the recorded values. Since its release 0.1.1-rc.15 it reads a birth time from 1972, when leap seconds began, to 2 October 2027 as UTC: atomic time comes from the IERS leap seconds, and the Earth's rotation, which the ascendant and midheaven turn with, from the IERS measurements of UT1 and their predictions. For other dates it takes ΔT, as it did for every date from 25 September 2026 until that release, from Stephenson, Morrison and Hohenkerk's 2016 reconstruction before 1941, from US Naval Observatory and IERS records after it, and from the IERS predictions for the year ahead. The reconstruction's 32 values are from Table S15 of their paper, Proceedings of the Royal Society A 472, 20160404, rounded to 0.01 seconds and used under CC BY 4.0. From 1962 on it is within 0.09 seconds of the IERS value on every day, and each chart records the value it used and its uncertainty. Before that it used a fixed formula, which on 22 September 2026 read 75.5 seconds where the IERS value is 69.2, and which on its own moved the Moon about 3.5 arcseconds.

Swiss Ephemeris and this engine's planetary series both descend from JPL development ephemerides, and the engine's Moon comes from an older lunar theory, so this is two implementations agreeing, not a check against observation. The date list, the pinned versions, which Swiss data answered each call, the statistics quoted here and the tools that regenerate every row are in the benchmark record.

Angles and houses

The ascendant and midheaven are computed from Greenwich apparent sidereal time, your birthplace coordinates, and the true obliquity of the ecliptic of date: the mean obliquity (IAU 2006) plus the nutation in obliquity, the same model the sidereal time uses. We offer whole sign houses (the oldest system — each house is one complete sign) and Placidus (the most common modern system, computed by iterative semi-arc division). Placidus is mathematically undefined inside the polar circle; where the latitude is 90° minus the obliquity or more, about 66.56°, we fall back to whole sign and say so on the chart.

Natal aspects and orbs

Natal charts test every pair from the Sun through Pluto for the five major aspects below. The nodes are not included. An aspect is shown when its distance from exact is at or below the listed orb; any pair containing the Sun or Moon uses the wider luminary orb.

Applying and separating labels use the bodies’ computed longitude speeds. An aspect is applying while its distance from exact is shrinking, judged from the two bodies’ relative speed at that moment, and separating when it is exact or growing. The displayed orb is the current absolute distance from exact. Fixed-chart synastry and composite aspects do not receive applying or separating labels.

Progressions, returns, and composites

Secondary progressions use the day-for-a-year method: one civil day after birth stands for one tropical year (365.2422 days) of life. We progress the planets only — progressed house angles require a convention we haven't adopted, so we don't show them. A solar-return chart is a full chart cast for the instant the Sun returns to its natal longitude. The Sun moves slowly, so a small error in its position becomes a larger one in time: against NASA JPL that instant runs from about 30 seconds early to about 40 seconds late through the year, which moves the return chart's angles by up to about a quarter of a degree. A composite chart takes the shorter-arc midpoint of each pair of matching planets across two charts; composite houses require a location convention we won't fake, so composite charts are shown without houses.

Time zones

A birth chart is only as good as its clock conversion. For births from 1970 on, we resolve your birth time with the IANA time-zone history in your browser's host ICU data, daylight saving and its regional rules included. For earlier births the history, wartime clock changes included, comes from a pinned release of the IANA database (below); before the date each place adopted a legal time, we read the birthplace's own local mean time, which runs to seconds.

• Skipped times (spring-forward gaps) shift forward across the gap — the standard convention — and the chart says so.
• Repeated times (fall-back folds) use the earlier pass, flagged on the chart.
• Very old dates, from before a place adopted a legal time, use the local mean time of the birthplace itself, worked out from its longitude at four minutes of time per degree, as professional software does. The time zone data records only its reference city's mean time, which for a town a few hundred kilometres away can be off by a quarter of an hour or more; Buffalo in 1870 ran 19 minutes 29 seconds behind New York. The date each place's local mean time ended comes from the IANA database's fuller historical records (release 2025c).
• From then until 1970, the legal time comes from the same release. That includes national mean times, such as Paris Mean Time from 1891, and the older records the database keeps apart for places whose clocks have matched another city's since 1970; its maintainers consider those records less reliable than the rest. Browsers leave them out and give such a place the other city's history, so for about 85 of the 356 time zones in our city index the browser's legal time before 1970 differs from the one used here at some point, 55 of them by an hour or more. Sweden, Norway, Denmark, Iceland and the Netherlands are among those 55. At noon on 1 July 1947, for example, a Stockholm birth reads 10:00 UTC with Berlin's summer time in the browser's history, where Sweden kept +1:00 and the chart uses 11:00. A handful of old zone names, none of them in the city index, keep the browser's history throughout, because their records differ after 1970 as well or browsers do not know them.

Every birth chart result lists its computed UTC instant, so the conversion is yours to check.

Birthplace search

Place lookup runs against a bundled index of ~34,000 cities from GeoNames (CC BY 4.0), each carrying its IANA time zone. Coordinates are stored to ~1 km precision — far finer than a birth chart needs.

Numerology

The numerology calculator is a different tradition from everything above: no sky and no clock, only arithmetic on a birth date and a name. It uses the Pythagorean system. Letters take the values 1 to 9 in cycles (A is 1, I is 9, J is 1 again, and so on to Z, which is 8). The birth date's month, day, and year are reduced separately, with 11, 22, and 33 kept as master numbers, then added and reduced once more; that final total is the Life Path, and the calculator shows the whole chain, such as 16/7. Name numbers reduce each name part before the parts are added, the convention most modern numerologists follow, so master numbers and the karmic-debt totals 13, 14, 16, and 19 are neither invented nor hidden. Y counts as a vowel unless it directly follows another vowel or opens a name before one, and any Y can be flipped by hand. Personal years, months, and days reduce everything to a single digit. Accents fold to plain letters, hyphens and apostrophes are removed without splitting a name, and letters outside the Latin alphabet are refused rather than dropped. The arithmetic is exact and repeatable and is checked against fifteen worked cases in the test suite; the meanings attached to each number are conventions of the tradition, not measurements or predictions.

Privacy

The entire chart calculation happens in your browser. Your birth date, time, and place are not sent to a chart API, and there is no account requirement or analytics attached to birth data. Charts you save live in your browser's local storage first, deletable by you at any time. If you sign in to an account, your saved charts and their birth details upload to your Supabase account and are protected by row-level security. Guide sends each question to OpenAI; if you press “Attach my chart”, which is offered only in the encrypted sync preview, a placements-only summary goes with each message while “Using my chart” remains on. The assistant never attaches the saved name, birth fields, or coordinates, though the summary's positions still give the birth date and time, and its ascendant and midheaven, kept to the whole degree, the birthplace roughly. A transit calendar or a compatibility invitation sends a chart's positions, which still give the birth date and time; theprivacy page lists every case.

Honest limits

• Chiron and the asteroids aren't included yet (the engine's remit is major bodies); they're planned via public-domain JPL data.
• When birth time is unknown, the site uses 12:00 local civil time as a reference for body positions. It omits the rising sign, angles, and houses, and it marks the Moon's sign as unverified, because the Moon can change sign during the day. A link, calendar, invitation, or card shared from such a chart carries the positions at 12:00 UTC on the birth date instead, because noon at the birthplace would give away its time zone or, before standard time, its longitude.
• Supported birth years: 1800–2199.
• The JPL checks validate astronomical position calculations, not astrological interpretation. Interpretations here are traditional and reflective, not scientifically validated predictions.

Daily publication system

Zodiacs.org is maintained through automated editorial systems rather than a traditional human editorial staff. A model is not allowed to invent a sky fact or approve its own output. The daily system starts with a deterministic noon-UTC snapshot: body positions, lunar phase, and any exact events covered by that month’s committed transit file. Missing event coverage is labeled as unavailable rather than presented as a quiet day.

Today’s short readings are rendered from versioned local sentence templates. Every published line carries stable evidence IDs for its source position or event and, where relevant, the derived solar house. A separately implemented astronomy audit recomputes positions, lunar state, event geometry, and the monthly day slice. A deterministic copy check then rebuilds all twelve readings, checks their IDs, rejects unsafe certainty and restricted advice, tests sign-to-sign distinctness, and compares hashes. That copy check intentionally reuses the versioned renderer and is not described as an independent second implementation. The same process is replayed across the previous 30 days on every run.

Those evidence IDs establish the astronomical input and the derived whole-sign solar house. Phrases about a house’s life themes are versioned editorial conventions, not astronomical measurements; the template ID identifies that interpretive layer instead of disguising it as an observed fact.

AI agents may propose new templates or a constrained selection system in a future edition, but free-form model text cannot pass the current release gate. The editorial constitution is public. The exact policy version, generation mode, source hashes, and verification result for the live edition are available in the daily publication record. Material fixes appear in the correction log.

The computed dates behind the calendars — retrogrades, ingresses, moon phases, eclipses, and today's snapshot — are also published for reuse as machine-readable JSON under CC BY 4.0.

Found a discrepancy? We treat accuracy reports as bugs. The sky is checkable, and so is our arithmetic.