Felderformatiere

Ein Modell, das den Feldnamen errät, bekommt entweder 400, oder, schlimmer noch, eine sichere Antwort über eine andere Karte. Unten steht der genaue Vertrag.

Körper der Kartenanfrage

Feld	Typ und Format	Erforderlich
`date`	`YYYY-MM-DD`, und es muss ein echter Kalendertag sein	ja
`time`	`HH:mm:ss`	ja, oder `timeUnknown: true`
`timezoneOffset`	Zahl, Stunden von UTC, z.B. `5.75`	nein, standardmäßig `0` (UTC)
`timezone`	IANA-Zonenname, z.B. `Europe/Kyiv`, oder `auto`	nein, und wenn gesendet, ersetzt es `timezoneOffset`
`latitude`	Dezimalgrad, Nord positiv	ja
`longitude`	Dezimalgrad, Ost positiv	ja
`houseSystem`	ein Buchstabe, standardmäßig `P`	nein
`city`	String, nur Beschriftung	nein
`zodiacType`	`tropical` oder `sidereal`	nein

Kurzschreibweisen werden abgelehnt

lat, lon, lng, long, tz, tzOffset, utcOffset, gmtOffset, timeZone, time_zone geben 400 INVALID_FIELD mit dem korrekten Feldnamen zurück:

{ "error": { "code": "INVALID_FIELD",
  "message": "Unsupported field \"tz\". Rename it to \"timezoneOffset\" (numeric hours from UTC, e.g. 5.75; a zone name goes in timezone)." } }

Groß-/Kleinschreibung und Trennzeichen des Wertes sind nicht erlaubt: TZ_Offset und tzoffset werden ebenso abgelehnt. Alle gefundenen Felder werden auf einmal gemeldet, nicht nur das erste, damit du sie in einem Durchgang korrigieren kannst.

Der Grund ist streng: Vor dieser Prüfung hat ein Feld, das die API nicht gelesen hat, stillschweigend einen Offset von 0 zurückgegeben, und die Antwort war eine sichere Karte für UTC. Drei Stunden Offset entsprechen etwa 45° Aszendent, also einem anderen aufsteigenden Zeichen, und das ohne Warnung.

`timezone`: Zonenname statt Offset

Der Offset muss der sein, den die Uhren genau an diesem Datum zeigten, und man kann ihn manuell leicht falsch angeben: Kiew im Mai 1990 folgte der Moskauer Sommerzeit, UTC+4, nicht +3. Sende timezone und der Server nimmt den Offset aus der Zeitzonendatenbank, inklusive Sommerzeit.

{ "date": "1990-05-15", "time": "14:30:00", "timezone": "Europe/Kyiv",
  "latitude": 50.45, "longitude": 30.52 }

auto bestimmt die Zone anhand von latitude und longitude. In Grenznähe ist der Name genauer.
Wenn timezone und timezoneOffset zusammen gesendet werden, gilt timezone. input.timezoneOffset in der Antwort zeigt den verwendeten Offset.
Die Zeit, die zweimal vorkam (wenn die Uhren zurückgestellt wurden), wird beim ersten Mal genommen. Die Zeit, die nicht vorkam (wenn vorwärts gestellt wurde), erhält den Offset, der vor der Umstellung galt.
Ohne time (nur Datum oder timeUnknown: true) wird die Zone am lokalen Mittag gelesen.
Abgelehnt mit 400 INVALID_FIELD: leerer Wert, Abkürzungen wie EST oder PST, Offset als Text wie +03:00, Namen, die nicht in der Datenbank sind, und auto ohne Koordinaten. UTC und GMT werden akzeptiert.
Jedes Objekt wird separat verarbeitet, sodass chart1 und chart2 in unterschiedlichen Zonen sein können.

`houseSystem`: Buchstabe, nicht Name

Genau diese 25 Codes der Swiss Ephemeris werden akzeptiert:

P K R C E W B M O A T V D F G H I i L N Q S U X Y

Die Groß-/Kleinschreibung ist bedeutend: I ist Sunshine nach McRansky, i nach Trundle. Der Systemname ("Placidus", "Koch") gibt 400 zurück. Früher funktionierte es zufällig, weil die Engine aus dem String nur den ersten Buchstaben liest, und aus demselben Grund gab "Zodiac" stillschweigend Placidus zurück.

Unbekannte Geburtszeit

Statt einer erfundenen Mittagszeit sende timeUnknown: true und übergebe kein time. Dann kommen houses, houseAspects, chartSect und siderealTime als null zurück, nicht erfunden. Details: API-Konventionen.

Unbekannte Schlüssel werden nicht abgelehnt

Der Body akzeptiert zusätzliche Felder stillschweigend: ein unbekannter Schlüssel wird einfach ignoriert. Deshalb wird ein Tippfehler im Feldnamen, der nicht in der obigen Ablehnungsliste steht, nicht bemerkt. Siehe die Spezifikation: /v1/openapi.json.

Weiter

Hilfreich?

Запропонувати правку

Zuletzt aktualisiert: 18.09.2026