Skip to main content

​
Calendar boundaries

Every date GEOMETRY returns is a bare YYYY-MM-DD string. They do not all mean the same thing. Some are cultural year boundaries anchored to a tradition’s own civil timezone. Others are sky events anchored to GMT. A single tool response can contain both; the JSON does not label which family each date belongs to.

​
Two date families

If you compare GEOMETRY to another source and see a one-day difference, start here. Cultural years disagree because of a civil convention; sky events disagree because of a timezone offset from GMT.

​
The governing rule

Tools take a bare calendar date — YYYY-MM-DD, no time, no timezone. Each cultural year is stored as a date window in its tradition’s civil frame; lookup is a plain date-in-range match. No timezone conversion happens at request time. GEOMETRY does not know the user’s location, birth time, or your server’s zone. It uses the date you send and answers in each tradition’s own terms. Converting at request time would require guessing a birth time and place that were never provided.

​
Cultural years — which anchor each system uses

Timezone-neutral means no timezone applies — not that UTC was chosen. The Hebrew calendar is arithmetic (Metonic calculation), with no single astronomical instant to place in a zone. Dreamspell is a fixed count from a July 26 anchor. Neither shifts by a day based on the caller’s zone. Chinese, Vietnamese, and Vedic dates follow the civil convention each tradition publishes. Re-anchoring them to UTC would disagree with common references (Hong Kong Observatory, drikpanchang) on a meaningful fraction of years, with no astronomical benefit.

​
The Persian exception

Persian years use the equinox date in GMT, not Iran’s official civil rule. This is deliberate — and the one case where GEOMETRY can disagree with a Persian calendar library. Iran’s official Solar Hijri calendar places Nowruz on the day of the equinox in Tehran local time (UTC+3:30), rolling to the next day when the equinox falls after Tehran solar noon. GEOMETRY uses the Gregorian day that contains the equinox instant in GMT. The two rules disagree on roughly a quarter to a third of years. 2026 is one of them: If you reconcile against an Iranian calendar library, expect this. It is a documented convention choice so the Persian year stays consistent with the same equinox table that drives season anchors. To obtain the Tehran civil date, derive it in your app from the equinox instant. GEOMETRY will not switch conventions silently.

​
Hebrew days begin at sunset

The Hebrew calendar starts each day at sunset, not midnight. GEOMETRY stores the civil Gregorian date on which the Hebrew date falls. Example — Rosh Hashanah 5787: observance begins the evening of September 11, 2026; GEOMETRY’s Hebrew year 5787 starts on September 12, 2026 (the civil day). Both are correct; they answer different questions. If your product needs the sunset boundary, treat the eve as one day earlier. Hebrew years also vary in length by design. 5787 runs 385 days (leap year with Adar I). Lengths of 353–355 and 383–385 days are normal.

​
Sky event dates are GMT

Moon phases, seasons (solstices and equinoxes), and retrograde windows are astronomical instants. Tools return the Gregorian day that contains each instant in GMT.

​
Moon phases and seasons

Clock time is not in the MCP payload — only the GMT calendar day. "prev_anchor_dt": "1990-05-09" means the full-moon instant fell somewhere on May 9, 1990 GMT, not necessarily that evening in the user’s city.

​
Planetary retrogrades (including shadow)

Retrograde windows are Greenwich-anchored. Each cycle can include pre-shadow, station retrograde, station direct, post-shadow, and cazimi (when present). Worked example — Mercury cycle covering mid-May 1990 (GMT days returned in the tool payload): In retrogrades_active, each body has a phase of pre_shadow, retrograde, or post_shadow for the query date, plus station dates as GMT calendar days (retro_start_dt, retro_end_dt, and cazimi_dt when present). Same rule as moon and seasons: the tools return the GMT day, not the clock time. If a local ephemeris app shows a station one calendar day later than GEOMETRY, that app is usually converting to local time. GEOMETRY does not. A local-time source can disagree with the GMT day. An instant lands at a random time of day, so the chance a local date differs from GMT is roughly the zone offset ÷ 24: Comparing GEOMETRY full-moon dates to a Singapore local almanac, expect about a one-day difference on roughly a third of them. Both can be correct: GMT day vs local day. Local dates: convert in your app from the GMT day and the user’s zone. Without clock time on the wire, only whole-day shifts are possible. Same payload, different anchors. A moon-phase date in GMT can sit next to a lunar year anchored to CST. Shared JSON does not imply a shared timezone.

​
What this means near a boundary

If a birth date falls within a day or two of a year boundary, which system you read matters:
  • You send the civil date. GEOMETRY does not reinterpret it.
  • A birth immediately before a lunar new year belongs to the previous animal year. February 16, 2026 is still the snake year; February 17, 2026 is the first day of the fire horse.
  • Different systems roll over at different times of year, so the same date can be late in one cultural year and early in another. That is expected.
  • No inferred birth time. Hour-level precision at a boundary belongs in your application, using birth time and place you collect there.