How We Verify Accuracy
Venusward runs on Swiss Ephemeris astronomical data. This page lists exactly how that calculation layer has been checked — the tests we ran, the numbers they produced, and what each test does and doesn't prove. The same house system, ephemeris mode, and time zone shown here are disclosed again, per calculation, on every chart's own "Calculation Transparency" card.
Ephemeris precision: 500 position, 220 velocity, and 220 retrograde comparisons
We independently recomputed 500 planetary-position values, 220 velocity values, and 220 retrograde-motion booleans across 20 birth-data test cases — chosen to cover DST boundaries, historical time zones, and polar-latitude house-system edge cases — and compared every one against an independently computed reference. Every difference came out ≤0.01°.
What this does and doesn't prove. The reference values were computed independently with pyswisseph (a separate Python binding to Swiss Ephemeris — a different language runtime, author, and build than the Node package this site runs) against the real Swiss Ephemeris data files (sepl_18.se1 / semo_18.se1) published in Astrodienst's own official GitHub release repository — the same data astro.com's own website is built on. This verifies that our time-zone conversion, Julian-day math, and calculation-binding layer are correct. It is not the same thing as manually looking up each chart on astro.com's website, and it is not a third-party certification of this site — both binding layers ultimately implement the same published Swiss Ephemeris algorithms, so this test mainly rules out mistakes on our side rather than independently validating Swiss Ephemeris itself against a wholly different data source.
Independent time-zone conversion check
Converting a local birth time into the correct UTC instant — across DST transitions, historical time-zone changes, and the international date line — is exactly the kind of step that is easy to get subtly wrong. We ran 20 test cases through that conversion a second time, independently, using Python's zoneinfo library instead of our own Node/ICU code path. Every one of the 20 resulting Julian Day (UT) values matched to 0.000000 seconds.
Production environment verification
The precision numbers above were confirmed on a development machine. On August 4, 2026, we ran the same class of checks directly against the live production deployment: 101/101 automated checks passed, covering the native Swiss Ephemeris module loading correctly in production, time-zone data completeness on the production server, and six full chart calculations matching our frozen local baseline to within 0.000001° (1e-6°).
Place and time-zone data
Birthplace lookup uses a static database of 69,533 cities and towns across 370 time zones (GeoNames cities5000). The birthplace field requires selecting an entry from the dropdown — free-text entry isn't accepted — specifically to prevent the mismatched-timezone errors that free-text city names can cause. Towns with fewer than 5,000 people aren't in this database; we prompt those users to select the nearest larger city instead.
Calculation conventions
Every one of these settings — plus the exact house system, ephemeris note, and time zone actually used — is shown again on the Calculation Transparency card on your own chart page, not just claimed here in the abstract.
The sidereal (Lahiri) view has been cross-checked against an independent Python binding (pyswisseph) for all 20 of this page's frozen benchmark cases — Sun, Moon, Venus, and the Ascendant — with the largest difference smaller than 0.000001°. That check confirms the sidereal calculation and ayanamsa wiring against a second, independently maintained implementation; it hasn't yet been run against any external site's own sidereal output.
Aspects and orbs
Every chart checks for five aspect types, using one orb (allowed margin of error) per aspect type, applied the same way across every planet pair:
These are widely used, textbook-standard orbs — astrology tools differ on orb settings, so we publish ours rather than leave you guessing. Minor aspects (quincunx, semi-sextile, and similar) aren't calculated. The Ascendant and Midheaven don't participate in aspects. The North Node and South Node sit exactly 180° apart by definition, so that pairing isn't listed as an aspect — it would be true of every chart and wouldn't tell you anything.
Unknown birth time
If you check "I don't know my exact birth time," your chart is calculated for noon on your birth date instead of a specific clock time. Rising sign and house positions aren't shown in that case — without a real birth time we can't calculate them, and we won't guess. Sun and planet positions (sign placements, aspects between planets) stay accurate either way, since those don't depend on the hour of birth.
Time zone conversion
Birthplace is selected from the city dropdown described above, never typed in as a UTC offset — the correct IANA time zone for that place and date is looked up automatically, then converted using standard ICU/IANA time-zone data. That data includes historical time-zone changes and discontinued daylight saving rules (mainland China's 1986–1991 DST period, for example), not just each zone's current rule. Twice a year, daylight saving transitions make one wall-clock time occur twice (in autumn) or not exist at all (in spring, when clocks skip forward); this site specifically checks for both cases rather than silently picking an arbitrary interpretation.
What this page doesn't verify
Everything above is about calculation accuracy — degrees, minutes, and seconds of a real astronomical position. It says nothing about whether astrology's interpretive claims are scientifically valid; that is a separate question this site takes no position on. Astrology is offered here for self-reflection and entertainment, not as a factual claim about your future or your character.
Read more about who builds this and how reports are written on the About page, and see the full AI Disclosure page for exactly how drafting and human review work.