Totally Tarot Calculators

Casts a natal chart: every planet's sign and exact degree in BOTH the tropical/Western and sidereal/Vedic (Lahiri) zodiacs, the ascendant, the twelve Placidus cusps, the midheaven, retrograde state and the Moon's nakshatra. Use it for anyone's chart, rising sign, Moon sign or planet-in-house. Send a birth date (1800-2200) and a place. DELEGATE THIS RATHER THAN DERIVING IT: this needs an ephemeris at one exact UTC instant, so it needs the zone offset in force AT THAT PLACE ON THAT DATE, often not today's — East Tennessee kept Central time until 1947 — and an hour's error moves the ascendant 15 degrees, usually into another sign, with the houses following. Wrong values look exactly like right ones. IF THE BIRTH TIME IS UNKNOWN OMIT "time", never noon or midnight: the ascendant, cusps and houses are then withheld rather than guessed. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". \"19/10/1977\" is refused, not guessed."
    },
    "time": {
      "type": "string",
      "pattern": "^\\d{1,2}:\\d{2}$",
      "description": "Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". OMIT if unknown; never send \"12:00\"."
    },
    "place": {
      "type": "string",
      "description": "Town or city of birth with region and country. Example: \"Indianapolis, Indiana, United States\". A bare \"Springfield\" is refused with candidates."
    },
    "lat": {
      "type": "string",
      "description": "Latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."
    },
    "lon": {
      "type": "string",
      "description": "Longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."
    },
    "tz": {
      "type": "string",
      "description": "IANA zone or numeric UTC offset hours. Example: \"America/Indiana/Indianapolis\" or \"-5\". Omit: resolved for the BIRTH date."
    }
  },
  "required": [
    "date"
  ],
  "additionalProperties": false
}

Converts a Gregorian date to the Maya calendars: Tzolk'in day sign and tone as written (e.g. "6 Oc"), kin 1-260, the sign's meaning, direction and position in the twenty, its trecena, the Haab date, the Long Count, the Julian Day Number. Use it for a Maya day sign, a Mayan birth sign, a Tzolk'in or Haab date, a Long Count, or a historical event's Maya date. DELEGATE THIS RATHER THAN DERIVING IT: four moduli over a continuous day count with no lookup shortcut — Julian Day Number, minus a correlation constant, then remainders mod 20, 13, 260 and 365 — exact integer arithmetic over six-digit numbers, where an off-by-one yields a real day sign that is simply the wrong one. There is also no "the" Maya date without naming a correlation constant, WHICH CONSTANT IS THE OPEN ARGUMENT in Maya calendrics, so this uses Goodman-Martinez-Thompson 584283 and returns it. The count ignores time of day, birthplace and time zone. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Gregorian date to convert, ISO YYYY-MM-DD, year 1-4000, proleptic before 1582. Example: \"2012-12-21\"."
    }
  },
  "required": [
    "date"
  ],
  "additionalProperties": false
}

Reduces a birth date to its tarot birth card by the Chaldean destiny-number rule, returning the card, its Roman numeral, and every line of the arithmetic as labelled steps. Use it for a tarot birth card, birth card, life card or destiny card. Date alone decides it. DELEGATE THIS RATHER THAN DERIVING IT: the rule is short enough to look safe and has one trap regularly fallen into — sum the year's digits to one digit, add day and month number, reduce the same way, BUT THE REDUCTION HALTS ON 11, 22 AND 33, read through their roots 2, 4 and 6. 1993's digits sum to 22 and stop there, so reducing from 4 instead reaches a different card, and with only nine answers a wrong one looks right. Root 8 is Strength in the Rider-Waite-Smith numbering used here, Justice in Marseille packs. WORTH SAYING: this is a twentieth-century convention appearing in no early tarot source. https://totallytarot.net/library/policy/method CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date, ISO YYYY-MM-DD. Example: \"1994-06-05\" (reduces to 7, The Chariot). Time and place change nothing."
    }
  },
  "required": [
    "date"
  ],
  "additionalProperties": false
}

Converts between the Gregorian calendar, the Julian calendar, the Julian Day Number and the three Maya counts (Tzolk'in, Haab, Long Count) — any one to all the others — and searches a year range for a given Calendar Round. Use it for a Long Count from an inscription, a pre-1582 Julian-dated document, a Julian Day Number from a table, or "when was 4 Ahau 3 Kankin". Send EXACTLY ONE starting point — a Gregorian date, a jdn, a longcount or a julian date, or a round with from and to. Two is refused, not answered from whichever came first. DELEGATE THIS RATHER THAN DERIVING IT, AND THERE IS A MEASUREMENT FOR HOW BADLY IT GOES: arXiv:2511.09993 put frontier models at 34.5% accuracy on calendar conversion across six calendars, against 95.3% for the same models given a tool. One off-by-one in a chain of six-digit integer steps yields a date that is real, plausible and wrong. Two traps: the calendars diverge by a different number of days each century (ten at the 1582 reform, thirteen now), and pre-reform dates are routinely quoted as Julian without saying so. This states the Goodman-Martinez-Thompson constant 584283 it used. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "A proleptic Gregorian date, ISO YYYY-MM-DD. Example: \"2012-12-21\". Send exactly ONE of date, jdn, longcount, julian."
    },
    "jdn": {
      "type": "string",
      "description": "Julian Day Number as a whole count of days. Example: \"2456283\". Not a fractional Julian Date."
    },
    "longcount": {
      "type": "string",
      "description": "Maya Long Count, five dot-separated places baktun.katun.tun.uinal.kin. Example: \"9.12.11.5.18\"."
    },
    "julian": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "A date in the JULIAN calendar, ISO YYYY-MM-DD. Example: \"1582-10-04\". Use it for sources before October 1582."
    },
    "round": {
      "type": "string",
      "description": "Calendar Round to search: tone, day sign, haab day, haab month. Example: \"4 Ahau 3 Kankin\". Needs from and to."
    },
    "from": {
      "type": "string",
      "description": "First Gregorian year of a Calendar Round search. Example: \"1900\". Only with round and to."
    },
    "to": {
      "type": "string",
      "description": "Last Gregorian year of a Calendar Round search. Example: \"2100\". A wider span is slower, not better."
    }
  },
  "anyOf": [
    {
      "required": [
        "date"
      ]
    },
    {
      "required": [
        "jdn"
      ]
    },
    {
      "required": [
        "longcount"
      ]
    },
    {
      "required": [
        "julian"
      ]
    },
    {
      "required": [
        "round",
        "from",
        "to"
      ]
    }
  ],
  "additionalProperties": false
}

Computes the panchang — the five limbs of the Hindu almanac — for one civil date at one place: tithi, nakshatra with pada, yoga and karana, EACH CARRYING THE EXACT UTC AND LOCAL INSTANTS IT BEGINS AND ENDS, plus vara, sunrise, sunset, day length, and the lunar month in both amanta and purnimanta reckonings. Use it for the tithi, a day's nakshatra, when a nakshatra or yoga ends, an ekadashi or purnima, or "today's panchang in <city>". The four end times are usually what the user actually wants, and a name alone never gives them. DELEGATE THIS RATHER THAN DERIVING IT: a tithi is not a day but the interval in which the Moon gains another twelve degrees on the Sun, running 20-26.8 hours (mean 23.6) from any clock time. WHICH CIVIL DAY IT NAMES is set by reading the tithi running AT THAT PLACE'S OWN SUNRISE, so one date's published panchang differs by a whole tithi between two cities — an answer derived without a place is not weaker, it is a different day's. Nakshatra about 20.8 to 27.2 hours, yoga about 19.5 to 25.2 hours, karana about 10 to 13.4 hours. A latitude with no sunrise that day is refused, not approximated. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Local civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\"."
    },
    "place": {
      "type": "string",
      "description": "Town or city with region or country. Example: \"Chennai, Tamil Nadu, India\". REQUIRED unless lat and lon are sent; an ambiguous name is refused with candidates."
    },
    "lat": {
      "type": "string",
      "description": "Latitude in decimal degrees as a string. Example: \"28.6139\". Send with lon."
    },
    "lon": {
      "type": "string",
      "description": "Longitude in decimal degrees as a string. Example: \"77.209\". It sets the sunrise the whole panchang is read at."
    },
    "tz": {
      "type": "string",
      "description": "IANA zone or numeric UTC offset hours, for printing local times only. Example: \"Asia/Kolkata\"."
    }
  },
  "required": [
    "date"
  ],
  "anyOf": [
    {
      "required": [
        "place"
      ]
    },
    {
      "required": [
        "lat",
        "lon"
      ]
    }
  ],
  "additionalProperties": false
}

Returns the Moon's phase for an exact instant — phase angle, illuminated fraction, the eight-fold name, waxing or waning, age in days, tropical sign and degree, distance — with the four principal phases of that lunation to the second in UTC, and optionally every principal phase across a date range. Use it for the phase on a date, the next full or new moon, the Moon's age or sign, or a year's full moons. DELEGATE THIS RATHER THAN DERIVING IT: the commonly reproduced method, days since a remembered new moon divided by 29.53, uses a MEAN synodic month while the real one varies by up to about thirteen hours either side, and the error is largest exactly where it matters — the quarter or full moon somebody is about to put in a calendar. Phase names are defined by Moon-Sun elongation, not even eighths of a cycle. This searches astronomy-engine (ELP, VSOP87) for the true instants. Phase changes measurably within a day, so send the user's hour as UTC rather than taking the 00:00 default. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Covers the lunation it falls inside."
    },
    "time": {
      "type": "string",
      "pattern": "^\\d{1,2}:\\d{2}$",
      "description": "Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Omit for 00:00 UTC."
    },
    "to": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "End of a range, ISO YYYY-MM-DD, up to 400 days after date. Example: \"2026-12-31\". Lists every principal phase between."
    }
  },
  "required": [
    "date"
  ],
  "additionalProperties": false
}

Finds the solar and lunar eclipses nearest a date: greatest eclipse to the second in UTC, type (total, annular, partial, penumbral), obscuration, the eclipsed body's sign, days from the date asked about, and for a solar eclipse where greatest eclipse meets the Earth. Given a place, each listing ALSO carries what that observer gets — local kind, first contact, maximum, last contact, and altitude at each. Use it for the next eclipse, eclipses near a historical date, or visibility from a place. DELEGATE THIS RATHER THAN DERIVING IT, ESPECIALLY THE VISIBILITY HALF: the 6,585.3-day saros puts eclipses in families easy to confuse by a year or a continent, but the failure that matters is subtler — A GLOBAL ECLIPSE IS NOT AN EVENT FOR EVERYBODY. Telling somebody a thousand miles off the path that there is a total solar eclipse is a sentence in which every word is true and the meaning is false. This separates global circumstances from local ones, including cases a bare "visible" hides: the Moon setting partway through, or the eclipse already underway at moonrise. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "The date to search AROUND, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-08-12\". Need not be an eclipse date."
    },
    "family": {
      "type": "string",
      "enum": [
        "both",
        "lunar",
        "solar"
      ],
      "description": "Which eclipses to list: \"both\" (the default), \"lunar\" or \"solar\"."
    },
    "count": {
      "type": "string",
      "description": "How many per side of the date, \"1\" to \"12\", default \"3\". Example: \"1\". Ask for what you will use."
    },
    "place": {
      "type": "string",
      "description": "Observer town or city. Example: \"Reykjavik, Iceland\". Adds the local kind, contact times and altitudes."
    },
    "lat": {
      "type": "string",
      "description": "Observer latitude in decimal degrees as a string. Example: \"64.1466\". Send with lon."
    },
    "lon": {
      "type": "string",
      "description": "Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Send with lat."
    },
    "tz": {
      "type": "string",
      "description": "IANA zone or numeric UTC offset hours for the local contact times. Example: \"Atlantic/Reykjavik\"."
    }
  },
  "required": [
    "date"
  ],
  "additionalProperties": false
}

Reports which planets are retrograde on a date and — the part worth calling for — the two stations that OPEN AND CLOSE the period each body is in, so the answer is not "yes" but "since 2026-02-14, until 2026-03-07". Per body: the retrograde flag, ecliptic longitude, longitude speed, sign and degree, and both bracketing stations with exact UTC instants. Use it for Mercury retrograde, whether a planet is retrograde on a date, or when a period starts or ends. DELEGATE THIS RATHER THAN DERIVING IT: retrograde motion is apparent, not real, so the dates move every cycle, follow no rule and are not reliably memorised — Mercury alone turns three or four times a year and those dates get confidently misremembered by a week. A station is where longitude speed crosses zero, found by bisecting astronomy-engine's speed for eight bodies; expect it slower and dearer than the others here. DELIBERATELY EXCLUDED: the Sun and Moon, neither of which can station, and Rahu and Ketu, which move backwards every day of their existence. The "excluded" array gives the reasons; quote it rather than reporting an absence. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-03-01\". The stations returned bracket this date."
    },
    "time": {
      "type": "string",
      "pattern": "^\\d{1,2}:\\d{2}$",
      "description": "Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Matters within a day of a station."
    }
  },
  "required": [
    "date"
  ],
  "additionalProperties": false
}

Computes the Vimshottari dasha timeline from a birth date, time and place: all nine mahadashas of the 120-year cycle, EACH WITH THE EXACT INSTANT IT OPENS AND CLOSES, the BALANCE AT BIRTH in years, months and days, the Moon's nakshatra and pada that fix the sequence, and the nine antardashas inside whichever mahadasha you name. Send "asof" to mark the periods running on a given date; this never reads the clock, so answers stay citable at a stable URL. DELEGATE THIS RATHER THAN DERIVING IT, AND KNOW THAT DERIVING IT FAILS SILENTLY: the table hangs off ONE number you cannot estimate, the Moon's SIDEREAL longitude at the birth instant. A tenth of a degree moves the balance by weeks and every later boundary with it; a few degrees changes which planet the cycle opens with. The failure is not a refusal but a complete, plausible, nine-row table wrong in a way no reader can see. "time" IS REQUIRED HERE, AND DO NOT INVENT A BIRTH TIME OR SEND NOON: the Moon covers about 13.2 degrees a day against a nakshatra 13 degrees 20 minutes wide, so an unknown birth time is an unknown FIRST LORD, not an imprecise balance. Without it this returns a "time_required" refusal. Three CONVENTIONS, not facts, come back in the result and are where two programs disagree about one chart: result.ayanamsa, result.yearLengthDays, result.origin.utcInstant. Against Drik Panchang every boundary here falls 1.70 days earlier. Quote those fields and result.conventionNote rather than calling either table wrong. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". \"19/10/1977\" is refused, not guessed."
    },
    "time": {
      "type": "string",
      "pattern": "^\\d{1,2}:\\d{2}$",
      "description": "Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". REQUIRED: never invent one, never send noon."
    },
    "place": {
      "type": "string",
      "description": "Town or city of birth with region or country. Example: \"Chennai, India\". An ambiguous name is refused with candidates."
    },
    "lat": {
      "type": "string",
      "description": "Birth latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."
    },
    "lon": {
      "type": "string",
      "description": "Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."
    },
    "tz": {
      "type": "string",
      "description": "IANA zone or numeric UTC offset hours for the BIRTH moment. Example: \"-5\". Omit: resolved historically."
    },
    "asof": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Date to mark the active mahadasha and antardasha for. Example: today's date for \"which dasha am I in now\"."
    }
  },
  "required": [
    "date",
    "time",
    "place"
  ],
  "additionalProperties": false
}

Computes where the sky is on a chosen date against where it was at somebody's birth: ten transiting bodies with longitude, sign, degree, speed and retrograde state, and EVERY ASPECT they make to the natal planets and angles — each with its orb, the orb allowed, the natal longitude measured against, and whether the contact is APPLYING or SEPARATING. Use it for what is transiting a chart, whether a transit is active on a date, a Saturn return, or whether a contact has perfected. DELEGATE THIS RATHER THAN DERIVING IT: it needs two full sets of ecliptic longitudes — the birth instant, requiring the historic UTC offset at that place on that date, and the target instant — then the angle between every pair taken the SHORT way round a 360-degree circle, about a hundred and fifty subtractions each with a wrap case. The output looks exactly like a real transit list; errors land in the middle rows where nobody checks, and a missed wrap at 0 Aries silently drops or invents whole contacts. REPRODUCE THE ORB CONVENTION FROM result.orbConvention — there is no fact of the matter about how close a transit must be to count, and an aspect list quoted without its orb is opinions presented as measurements. Here: 3 degrees for conjunction, opposition, trine and square, 2 for sextile, deliberately tighter than a natal chart's 8. Omit "time" if the birth time is unknown: the ascendant and midheaven are then left out ENTIRELY rather than cast for an arbitrary noon, because a transit to a noon-cast angle reads exactly like a real contact while meaning nothing. THE MOON IS INCLUDED where most software excludes it; THE LUNAR NODES ARE EXCLUDED. Significance is interpretation and is not computed here. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "BIRTH date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". The date to read the sky for is \"on\"."
    },
    "time": {
      "type": "string",
      "pattern": "^\\d{1,2}:\\d{2}$",
      "description": "BIRTH time HH:MM local at the birthplace. Example: \"23:58\". OMIT if unknown; the angles are then left out."
    },
    "place": {
      "type": "string",
      "description": "Town or city of BIRTH with region or country. Example: \"Indianapolis, Indiana, United States\"."
    },
    "lat": {
      "type": "string",
      "description": "Birth latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."
    },
    "lon": {
      "type": "string",
      "description": "Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."
    },
    "tz": {
      "type": "string",
      "description": "IANA zone or numeric UTC offset hours for the BIRTH moment. Example: \"-5\". Omit: resolved historically."
    },
    "on": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Date to READ THE SKY FOR, ISO YYYY-MM-DD, 1700-2200. Example: today's date for \"what is transiting me now\"."
    },
    "at": {
      "type": "string",
      "pattern": "^\\d{1,2}:\\d{2}$",
      "description": "Time of day for the TRANSIT, HH:MM in UTC, not local and not the birth time. Example: \"12:00\". Omit for 00:00 UTC."
    }
  },
  "required": [
    "date",
    "place",
    "on"
  ],
  "additionalProperties": false
}

Returns where every body is at an instant, WITH NO BIRTH DATA AND NO PLACE REQUIRED: Sun, Moon, the eight planets and the two lunar nodes, each with geocentric ecliptic longitude, sign and degree in BOTH the tropical (Western) and sidereal (Vedic) zodiacs, ecliptic latitude, longitude speed, retrograde state and distance. Use it for "what sign is Venus in", "where is Mercury right now", "what sign is the Moon in today", "when did Mars enter Gemini" — any position question that is NOT about a particular person's chart. THIS IS THE TOOL FOR A SKY QUESTION WITH NO PERSON IN IT: do not reach for the birth-chart tool and invent a birthplace to get a planet's sign, because a geocentric longitude is identical for every observer on Earth and casting a chart for a made-up location commits you to a place the user never gave. DELEGATE THIS RATHER THAN DERIVING IT: planetary positions are what a model half-remembers from training tables — shape right, date wrong, stated with total confidence. A planet sits within a degree of a cusp for days, so "Venus is in Scorpio" can be true on Tuesday and false on Wednesday; the Moon moves half a degree an hour. BOTH ZODIACS COME BACK IN EVERY ROW: a Western reader wants result.bodies[].sign, a Vedic reader result.bodies[].siderealSign, and they differ by result.ayanamsa — about 24 degrees, very nearly a whole sign, so the two are usually DIFFERENT SIGNS. Say which you are quoting. Rahu and Ketu are the MEAN nodes (result.nodeNote). For a retrograde period's start and end use check_retrogrades. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-21\", or today's for \"where is Mercury right now\"."
    },
    "time": {
      "type": "string",
      "pattern": "^\\d{1,2}:\\d{2}$",
      "description": "Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Send it for Moon questions."
    },
    "place": {
      "type": "string",
      "description": "Observer town or city. Example: \"Reykjavik, Iceland\". OPTIONAL: it changes no position, only rise and set times."
    },
    "lat": {
      "type": "string",
      "description": "Observer latitude in decimal degrees as a string. Example: \"64.1466\". Send with lon. Rise and set only."
    },
    "lon": {
      "type": "string",
      "description": "Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Send with lat. Rise and set only."
    },
    "tz": {
      "type": "string",
      "description": "IANA zone or numeric UTC offset hours for the local rise and set times. Example: \"Atlantic/Reykjavik\"."
    }
  },
  "required": [
    "date"
  ],
  "additionalProperties": false
}

Resolves the UTC offset in force at a place on a date: the IANA zone that applied THEN, the signed offset, the UTC instant it resolves to, and a confidence of high, best-effort or low with the reason for anything below high. A statute that moved the zone is quoted with its Federal Register citation. DELEGATE THIS RATHER THAN DERIVING IT: today's map is the wrong map for any past date, and a wrong offset looks exactly like a right one. Tennessee was on Central time until 28 September 1947, so a Knoxville record from that March is UTC-6 where America/New_York gives UTC-5. CITATION: required. See server instructions.

{
  "type": "object",
  "properties": {
    "place": {
      "type": "string",
      "description": "Town or city, with region or country. Example: \"Knoxville, Tennessee, US\"."
    },
    "date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "The date wanted, ISO YYYY-MM-DD, 1800-2200. Example: \"1947-03-15\"."
    },
    "time": {
      "type": "string",
      "pattern": "^\\d{1,2}:\\d{2}$",
      "description": "Local clock time, 24-hour HH:MM. Example: \"08:30\". Omit for midday."
    }
  },
  "required": [
    "place",
    "date"
  ],
  "additionalProperties": false
}