Date Out Of Supported Range
date_out_of_supported_range422
The date is outside our supported range (1800-01-01 to 2099-12-31). Use a date within bounds.
What this means
A date in the request falls outside the range our astronomical calculation engine supports. We use the Swiss Ephemeris for planetary positions and house calculations, and we ship ephemeris files covering 1800 through 2099. Dates outside that window have no underlying astronomical data, so no calculation is possible — the engine doesn't try to extrapolate.
When you'll see this
- A birth date earlier than 1800-01-01 was submitted (rare — typically a data-entry error or historical figure).
- A future date past 2099-12-31 was submitted for transit, return, or progression calculations.
- A typo in the date introduced an extreme year value (e.g.
1900typed as190). - A test or fixture used a placeholder date like
0000-01-01or9999-12-31.
Learn more about how this works
The Swiss Ephemeris provides high-precision astronomical data from approximately 13,200 BCE to 17,000 CE in its complete form, but we ship the practical subset that covers contemporary use: 1800 to 2099. Within that range, planetary positions are accurate to fractions of an arc-second. Outside, we'd have to either ship vastly larger ephemeris files (the full set is gigabytes) or extrapolate (which is mathematically meaningless for orbital mechanics over centuries).
The most common gotcha: some clients construct dates from user input without bounds-checking. If a user types 12-03-95 and your client parses it as 0095-03-12 instead of 1995-03-12, you'll hit this error for a date that looks reasonable on inspection but isn't.
Example response
{
"success": false,
"error": "date_out_of_supported_range",
"message": "Date is outside the supported range. Supported range is 1800-01-01 to 2099-12-31.",
"details": [],
"retry_after": null,
"doc_url": "https://docs.asterwise.com/reference/errors/date_out_of_supported_range",
"request_id": "req_01HXYZABCDEFGH",
"timestamp": "2026-05-25T12:34:56Z"
}
- Verify the date in the request matches what the user intended. Year-only typos are the most common cause.
- If you genuinely need calculations outside 1800-2099, those aren't supported — there's no fix on your side.
- For historical figures with pre-1800 birth dates, document them with approximate data but skip astrological calculations.
Validate date ranges client-side before submission. This catches the error earlier and gives clearer feedback.
Python:
Production handler
- Python
- TypeScript
import httpx
from datetime import date
MIN_DATE = date(1800, 1, 1)
MAX_DATE = date(2099, 12, 31)
def call_asterwise(url, headers, payload):
birth_date = date.fromisoformat(payload["birth"]["date"])
if not (MIN_DATE <= birth_date <= MAX_DATE):
raise ValueError(
f"Birth date {birth_date} outside supported range "
f"({MIN_DATE} to {MAX_DATE})."
)
response = httpx.post(url, headers=headers, json=payload, timeout=30)
response.raise_for_status()
return response.json()
const MIN_DATE = "1800-01-01";
const MAX_DATE = "2099-12-31";
async function callAsterwise(url: string, headers: HeadersInit, payload: any) {
const birthDate = payload.birth?.date;
if (birthDate && (birthDate < MIN_DATE || birthDate > MAX_DATE)) {
throw new Error(
`Birth date ${birthDate} outside supported range ` +
`(${MIN_DATE} to ${MAX_DATE}).`,
);
}
const response = await fetch(url, {
method: "POST",
headers,
body: JSON.stringify(payload),
});
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return response.json();
}
Avoid this error by
- Validate date ranges in your UI. Date pickers should constrain selection to 1800-2099.
- For dates parsed from free-text input, always check the resulting year is in a sensible range before submitting.
- In integration tests, include boundary cases (1800-01-01, 2099-12-31) so range handling is verified.
- Don't pad short years yourself ("95" → "1995"). Different conventions handle this differently; let a proper date parser do it.