true-solar-time-mcp

Korrektur der wahren Sonnenzeit für BaZi / Four Pillars-Diagramme — der Schritt, den die meisten Rechner überspringen.

Ein MCP-Server, CLI und TypeScript-Bibliothek, die eine aufgezeichnete Geburtszeit (Wanduhr + IANA-Zeitzone + Längengrad) in die tatsächliche Sonnenzeit am Geburtsort umrechnet. Deterministisch: gleiche Eingabe, gleiche Ausgabe, jedes Mal.

$ npx true-solar-time 1988-07-01 08:00 Asia/Shanghai 121.47

clock time    1988-07-01 08:00 (Asia/Shanghai, DST GMT+9)
true solar    1988-07-01 07:02
correction    -58 min
  DST         -60
  longitude   +6
  eq. of time -4
hour branch   辰 (2 min from 卯)
⚠ within 8 min of a branch boundary — cast both candidates

Warum es das gibt

Ein BaZi-Diagramm ist eine Funktion der Sonnenposition, aber Geburtsurkunden sind in bürgerlicher Uhrzeit geschrieben. Zwischen den beiden liegen drei Korrekturen, die fast jedes Diagramm-Tool — einschließlich der beliebten Open-Source-LLM-„Skills" — stillschweigend überspringt:

1. Historische Sommerzeit. China beobachtete von 1986 bis 1991 die Sommerzeit. Jeder, der in diesen sechs Sommern geboren wurde, hat eine Geburtsurkunde, die eine um eine Stunde vorgestellte Uhr aufzeichnet — genug, um einen ganzen Stundenast zu überqueren, und zur richtigen Nachtzeit auch den Tagespfeiler. Die IANA/ICU-Zeitzonendatenbank weiß das; die meisten Rechner fragen nie danach.

2. Längengrad. China erstreckt sich über vier geografische Zeitzonen und läuft auf einer Uhr. Um 07:10 Uhr Pekinger Zeit in Ürümqi ist die lokale Sonnenzeit kaum über 05:00 — zwei volle Äste entfernt.

3. Zeitgleichung. Wahre und mittlere Sonnenzeit weichen im Laufe des Jahres um bis zu ±16 Minuten voneinander ab (hier NOAA-Näherung, Fehler deutlich unter einer Minute). Anfang November kann sie allein ein Diagramm über eine Astgrenze bewegen.

Diese Bibliothek meldet auch zwei Dinge, die die meisten Tools nicht verraten:

• Ob Ihre Geburtszeit jemals existiert hat. In einer Frühlingsnacht springt die lokale Uhr von 01:59 auf 03:00; eine Geburtsurkunde mit 02:30 bezieht sich auf keinen realen Zeitpunkt. Wir erkennen die Lücke, melden ihre Breite und raten nie stillschweigend.

• Wie nah die korrigierte Zeit an einer Astgrenze liegt. Innerhalb weniger Minuten ist die ehrliche Antwort „beide Kandidaten berechnen", nicht falsche Präzision.

Related MCP server: OpenFate Bazi MCP

Was es bewusst nicht tut

Es erstellt keine Diagramme, wählt keine günstigen Elemente aus und interpretiert nichts. Das Erstellen ist ein gelöstes Problem mit guten Open-Source-Implementierungen; Interpretation hat keine eindeutige richtige Antwort und gehört nicht in eine Nachschlage-Bibliothek. Ein Schritt, sorgfältig ausgeführt.

Die vollständige Methodik — jede Konstante, jeder Schwellenwert und jede Konvention, einschließlich derer, die diese Bibliothek verwendet — ist veröffentlicht unter auspiceoracle.com/en/method. Drei durchgerechnete Beispiele mit vollständigen Ableitungen: der Geburtszeit-Test. Hintergrundessay: wahre Sonnenzeit.

MCP-Server

Gehosteter Endpunkt (keine Installation): https://auspiceoracle.com/mcp — zustandsloses streambares HTTP, keine Authentifizierung. Funktioniert als benutzerdefinierter Connector für claude.ai oder in jedem MCP-Client, der streambares HTTP spricht:

{
  "mcpServers": {
    "true-solar-time": { "url": "https://auspiceoracle.com/mcp" }
  }
}

Lokal (stdio):

{
  "mcpServers": {
    "true-solar-time": {
      "command": "npx",
      "args": ["-y", "true-solar-time-mcp"]
    }
  }
}

Werkzeuge:

• true_solar_time — vollständige Korrektur: korrigierter Zeitpunkt, DST/Längengrad/EoT-Aufschlüsselung (die drei ergeben immer genau die Summe), Stundenast, Grenzabstand, Erkennung nicht existierender Zeiten.

• hour_branch — Astzugehörigkeit und Grenzabstand für eine bereits korrigierte Zeit.

Der gehostete Endpunkt stellt zusätzlich cast_pillars bereit — sonnenkorrigierte vier Säulen mit verborgenen Stämmen, Na Yin und Glückszyklen, berechnet von der Produktions-Engine von Auspice Oracle (Closed Source; gleiche Konventionen wie die veröffentlichte Methodik). Nur Fakten — keine Stärkeurteile, keine Interpretation.

Wenn Sie eine BaZi-Fähigkeit oder einen Agenten bauen: Rufen Sie true_solar_time vor dem Erstellen auf und übergeben Sie die korrigierte Zeit an Ihren Ersteller. Ein LLM kann diese Umrechnung nicht im Kontext durchführen — die Zeitgleichung ist eine trigonometrische Reihe und die DST-Geschichte lebt in einer Datenbank, nicht in Modellgewichten.

Bibliothek

import { toTrueSolarTime } from 'true-solar-time-mcp'

const r = toTrueSolarTime(1992, 6, 15, 7, 10, 'Asia/Shanghai', 87.6)
// r.hour === 4, r.minute === 59, r.correctionMinutes === -130
// r.hourBranch === '寅' — two branches away from what the clock says

Konventionen, klar ausgedrückt

• Stundenäste wechseln zu ungeraden Stunden (子 beginnt um 23:00), jeweils 120 Minuten.

• Das Grenzrisiko-Flag verwendet einen 8-Minuten-Schwellenwert. Das ist eine Konvention, keine Physik — passen Sie es an Ihre eigene Toleranz an; Diagramme nahe der Grenze sollten unabhängig davon in beide Richtungen erstellt werden.

• Historische Zeitzonen stammen aus den ICU-Daten Ihrer Laufzeit (Node ≥ 18). Wir pflegen keine eigenen Tabellen.

• Wenn sich der Standard-Offset selbst mitten im Jahr änderte (Russland 2011), kann die DST/Längengrad-Aufteilung der Aufschlüsselung unvollkommen zuordnen; die Gesamtkorrektur wird immer aus dem tatsächlichen Offset berechnet und ist davon unberührt.

Beziehung zu auspiceoracle.com

Dies ist ein extrahierter Spiegel der Sonnenzeit-Schicht der Engine hinter Auspice Oracle. Die Haupt-Engine ist die Quelle der Wahrheit; die goldenen Tests hier verankern diesen Spiegel an denselben veröffentlichten Beispielen. Fehlerberichte sind sehr willkommen; PRs, die die obigen Konventionen ändern, werden abgelehnt (ein Konventions-Fork würde die veröffentlichte Methodik unwahr machen).

MIT © Shan Liu