How GetBirthChart calculates your chart

The calculation pipeline

Every chart follows the same deterministic sequence. The same birth data, with the same engine version and the same ephemeris and timezone data versions, produces the same chart:

• Birth input — date, time (if known) and place.
• Timezone — the birthplace is resolved to its IANA timezone, with historical daylight-saving rules applied.
• Universal Time — local time is converted to UTC for the instant of birth.
• Ephemeris — GetBirthChart Core computes planetary positions from Swiss Ephemeris data.
• Houses & angles — the Ascendant, Midheaven and house cusps are derived from time and location.
• Aspects — the angular relationships between planets are measured against defined orbs.
• Canonical chart — the result is a structured, versioned chart object.

Open-source calculation engine

GetBirthChart calculations are powered by the current coordinated gbc-astro 1.13.0 release, an open-source Python calculation engine also referred to as GetBirthChart Core. The source is publicly inspectable. The project concept record and version-specific release record are cited separately; neither certifies calculation correctness.

The pinned calculation contract is GetBirthChart Core v1.13.0: engine 1.13.0, natal schema 1.9.0, and Swiss Ephemeris 2.10.03 through pyswisseph. The coordinated 1.13.0 package is published and verified (released-and-verified); production web deployment is managed separately. The engine is licensed under AGPL-3.0-only.

Open-source source code (opens in a new tab) · Python package on PyPI (opens in a new tab) · Project Zenodo record (opens in a new tab) · Version 1.13.0 record (opens in a new tab) · Concept DOI 10.5281/zenodo.22052875 (opens in a new tab) · Version DOI 10.5281/zenodo.22206006 (opens in a new tab)

Building with GetBirthChart? Explore the API, SDKs, and developer integrations.

Calculation layer

The calculation layer produces deterministic chart data from supported inputs. For a known birth time that includes planetary positions and zodiac placements, houses, the four chart angles, major aspects, and retrograde state. It does not write interpretive prose.

Interpretation layer

Written interpretation uses astrology as a reflective framework. It synthesises meaning from the calculated placements, houses, aspects and how they interact — rather than reading each placement in isolation. It does not compute or invent planetary positions. Interpretation does not change the underlying chart facts.

This layer is not a scientific prediction of events. See our data sources and calculation guide for more detail.

Why timezone and Universal Time come first

A birth chart is a snapshot of the sky at one instant. To locate that instant on the astronomical clock, local birth time must be converted to Universal Time using the correct timezone — including the daylight-saving rules that were actually in force at that date and place.

GetBirthChart resolves the birthplace to an IANA timezone and applies historical offsets, rather than assuming a single fixed offset. This matters most for the time-sensitive parts of the chart: the rising sign, the angles and the houses.

Positions, houses and aspects

Planetary longitudes come from Swiss Ephemeris via GetBirthChart Core; the frontend does not approximate them. Each chart records which ephemeris and timezone data versions produced it, so a result is always traceable.

The default profile is tropical zodiac, Placidus houses, True Node, the Standard (`modern-major-v1`) aspect profile, and Chiron enabled. The public product supports Placidus, Whole Sign and Equal houses. Web-07 adds a feature-flagged Sidereal (Lahiri) path; the production flag remains off by default. Placidus is a time- and location-dependent quadrant system; Whole Sign makes each sign a house; Equal House creates twelve 30° houses from the Ascendant. The engine supplies planet-in-house results. The Midheaven is calculated independently and is not assumed to be the tenth-house cusp in every system.

The default aspect orbs are conjunction 8°, sextile 5°, square 7°, trine 7° and opposition 8°. Extended aspects are an optional profile where the product rollout allows them; custom aspect rules are a core/API capability, not a public calculator editor. Aspect identity, profile version, orb and applying/separating phase come from the engine.

The engine supports True Node and Mean Node without treating either convention as universally more correct. The default is True Node. Chiron is enabled by default; Lilith is opt-in with the exact supported Mean or True convention. Vertex and Part of Fortune are derived automatically for known-time charts when the required geometry is available.

Unknown birth time

An exact birth time strongly affects the Ascendant and the houses. When that time is unavailable, GetBirthChart omits the Rising sign, houses, angles, Vertex and Part of Fortune rather than inventing them. It does not treat midnight, noon or any other default clock time as the person’s known birth time.

The engine’s `unknownTimeAssessment` is the authority for date-level uncertainty. A stable Moon sign may be shown without an exact degree; if the allowed local-day interval contains more than one sign, the Moon sign and dependent aspects are not guessed. An incomplete or capped assessment fails closed. `anchorLongitude` is a reference position for the calculation, not the exact birth longitude.

The web product does not use an end-of-day overlay or a frontend approximation to override the engine assessment. Unknown-time output remains limited to facts that the interval supports.

See why birth time matters, birth chart without a birth time and what can still be calculated without exact time.

Public calculation test cases

The calculation core includes a public regression set built from trusted engine fixtures. It pins known-time planetary and angle values, relationship outputs, timezone edge cases, node and aspect conventions, unknown-time assessments, and explicit failure behavior so changes can be reviewed instead of silently changing chart facts.

The Hanoi default fixture records Sun longitude 221.14154838535987 and 14 default aspects. These are reproducibility examples, not a promise that every input has the same output. The Python helper `calculation_hash()` produces a versioned `v2:` plus 64 lowercase hexadecimal SHA-256 identity; the HTTP natal response intentionally does not emit `calculationHash`.

Read the public golden-test documentation on GitHub (opens in a new tab)

• Known-time natal regression — planetary positions, Ascendant, Midheaven, house cusp and Big Three.
• Relationship regression — composite positions, derived angles, overlays and aspect counts.
• Input boundaries — daylight-saving gaps and overlaps, historical timezone rules, date-line cases and leap days.
• Geometry boundaries — zodiac wrapping, house cusps, aspect orbs and high-latitude house-system limits.

Editorial oversight

Editorial standards for public reference pages and guides are overseen by Luis Pham. That includes how calculation is described, how interpretation is framed, and how unknown birth time is handled.

Every interpretation follows the same published, human-reviewed methodology, applied consistently to every chart rather than written page by page.

Precision and limitations

Chart results depend on input accuracy and on the engine, ephemeris files and timezone data in use. A birth time that is off by minutes can shift the rising sign and house cusps. Placidus houses are not calculated beyond the polar circles; the engine refuses that case rather than substituting another house system. Requested and effective calculation settings are retained so a fallback is not mistaken for a silent change.

We describe calculation behavior as implemented. We do not claim that astrology interpretation is scientifically validated.