Conventies BaZi

Voer één geboortemoment in twee BaZi-calculators in en je krijgt twee verschillende kaarten. Soms met een verschillende dagmeester, dat wil zeggen, het karakter waarop de hele lezing is gebaseerd. Dit is geen fout van één van hen. Onder elke kaart liggen vier conventies, elk met een eigen geschiedenis, en calculators passen deze stilzwijgend en verschillend toe.

Hieronder ons antwoord op elk van de vier. Ze worden aangekondigd in het disclaimer-veld van elk antwoord, dus een wijziging ervan is een breaking change, geen refactoring.

1. Waar het jaar begint: Lichun of Chinees Nieuwjaar

Ons antwoord: Lichun (立春), het exacte moment.

BaZi is een zonnesysteem binnen een lunisolaire kalender. De maandpilaren zijn gekoppeld aan de vierentwintig zonnetermen, dat wil zeggen aan de posities van de zon, niet aan de maanfasen, en het jaar volgt dezelfde logica: het keert terug op Lichun, rond 4 februari. Chinees Nieuwjaar is iets anders: de eerste nieuwe maan van het maanjaar, die varieert van eind januari tot eind februari.

Een geboorte in het tussengebied behoort volgens de ene regel tot het ene dier en volgens de andere tot het andere. Beide regels zijn geldig. Wij nemen Lichun, en het moment wordt uit efemeriden gehaald, niet uit de datum “4 februari”.

2. Waar de dag begint: 23:00 of middernacht

Ons antwoord: 23:00 volgens de klok van de geboorteplaats.

Een traditionele dag bestaat uit twaalf dubbele uren, en het eerste daarvan, het 子-uur, loopt van 23:00 tot 01:00. Alle andere vallen binnen één kalenderdag. Het 子-uur overspant middernacht, en uit dit ene structurele feit ontstaat de hele discussie: als het 子-uur de dag opent, behoort een geboorte om 23:30 al tot de volgende dag.

Dit is de as die de dagmeester verandert. Door de dagpilaar te verschuiven, heb je de kaart niet verfijnd, je hebt hem vervangen.

Daarom wordt een alternatieve lezing nooit verborgen. Elke kaartroute accepteert dayBoundary: "23:00" | "midnight" (standaard 23:00), en een geboorte in het 23:00-uur wordt geretourneerd met alternateDay: de dagpilaar en dagmeester volgens de regel die je niet hebt gekozen. De uurpilaar is voor beide hetzelfde, omdat het late 子-uur sowieso de stam van de volgende dag neemt. Van 00:00 tot 00:59 zijn alle scholen het eens over de dag, dus daar is geen alternatief.

3. Wordt de klok gecorrigeerd voor de lengtegraad van de locatie

Ons antwoord: op verzoek, en alleen voor dag en uur.

Gedurende het grootste deel van de geschiedenis van dit systeem kon de vraag niet ontstaan: lokale tijd was zonnetijd. Tijdzones zijn een uitvinding van het spoorwegtijdperk, en zodra een land volgens één klok leeft, valt die klok slechts op één meridiaan samen met de zon. China is een extreem geval: één zone over zestig graden lengtegraad, dus een geboorte in Kashgar wijkt bijna drie uur af van de zonale middag volgens de Peking-tijd.

curl -X POST https://api.astroway.info/v1/chinese/true-solar-time \
  -H "X-Api-Key: aw_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "date": "1995-06-15", "time": "09:20:00", "timezoneOffset": 8, "longitude": 75.9 }'

De correctie betreft dag en uur, en stopt daar

Lichun en de twaalf 節 zijn momenten op de wereldklok: de zon bereikt 315° één keer, en elke geboorte op aarde is ofwel ervoor, ofwel erna. De aflezing van een zonnewijzer vertelt waar de waarnemer staat, niet wanneer het moment aanbrak. Daarom betekent het toepassen van een gecorrigeerde klok binnen de grenzen van jaar en maand dat je ze de verkeerde vraag stelt.

De prijs van de fout is concreet: een geboorte in Peking om 23:00 op 4 februari 1988, dat wil zeggen zeventien minuten na Lichun, zou worden gecorrigeerd naar 22:31 en zou het vorige zonnejahr, de vorige maand, een andere dagmeester en een andere set van tien goden hebben gekregen. Wij hebben deze fout gemaakt en gecorrigeerd vóór de release.

4. Wat te doen met zomertijd

Ons antwoord: alleen de aanroeper weet dit.

Het veld timezoneOffset is de verschuiving waarmee de klok feitelijk liep op het moment van geboorte. Een geboorte in Peking in 1988 volgde UTC+9, niet +8, omdat China zomertijd hanteerde van 1986 tot 1991. Geen enkele rekenkunde aan onze kant kan dit uit de datum zelf herstellen, dus wij raden niet.

5. Wat het antwoord over zichzelf zegt

Elke kaartroute, /v1/bazi/chart, de analyseroutes, day-master, ten-gods, luck-pillars, yearly en monthly, retourneert een conventions-object: de grenzen van jaar en maand (lichun, jie), de gebruikte dayBoundary, of de ware zonnetijd is toegepast en met hoeveel minuten, de tijdzone met verschuiving en of zomertijd van kracht was, evenals de datum van het Chinese Nieuwjaar in het Gregoriaanse geboortejaar. timezone.assumed: true betekent dat noch de tijdzone, noch de verschuiving is verzonden, en de grenzen zijn gelezen volgens de Peking-tijd.

Een datum zonder tijd wordt gelezen als middag. Wanneer Lichun of 節 op deze lokale dag valt, hangt het antwoord af van het uur, dus het antwoord voegt boundaryInDay toe: het type grens, het lokale moment waarop de middag viel, en de jaar- en maandpilaren aan beide zijden.

De momenten van de grenzen zelf, 1900-2100

Elke jaar- en maandpilaar hangt af van het moment van Lichun en de overige elf 節, dus deze momenten zijn geverifieerd met twee bronnen die geen gemeenschappelijke code met de onze hebben. De twaalf termen die de maanden openen, voor elk jaar van 1900 tot 2100, dat wil zeggen 2.412 momenten, zijn onafhankelijk gevonden via JPL Horizons (DE441) met een nauwkeurigheid tot op honderdsten van een seconde. Onze momenten komen overeen binnen 4 seconden van 1950 tot 2025 en binnen 8 seconden tot aan 1900. Na 2025 moeten beide partijen voorspellen hoe de rotatie van de aarde zal afwijken, en de voorspellingen lopen langzaam uiteen, tot 21 seconden in 2100.

De datums van dezelfde termen volgens UTC+8 zijn geverifieerd met de tabellen van het Hong Kong Observatorium voor 1901-2100. 2.398 van de 2.400 komen overeen. Twee afwijkende, Daxue 1917 en Bailu 1927, vallen enkele minuten na middernacht, en Horizons staat daar aan de kant van onze datum.

Testen met een externe dataset

Jade Almanac heeft onder CC0 een vergelijking gepubliceerd van acht implementaties op dertien probes, speciaal gebouwd op deze vier assen: jadealmanac.com/bazi-calculator/conventions. De dataset meet conventies, niet correctheid, en zegt dit zelf.

We hebben onze POST /v1/bazi/four-pillars op alle dertien uitgevoerd. Het resultaat kan worden gereproduceerd met een commando in de repository en is vastgelegd in een test.

Probe	Wat het isoleert	Ons antwoord
1985-02-10	jaargrens	Yi-Chou, omdat Lichun al voorbij is
1990-06-15 23:30	dagovergang	dag Ren-Zi: de dag is al overgegaan
1988-02-04 23:00	Lichun en 23:00 samen	Wu-Chen Jia-Yin Geng-Yin Bing-Zi
1995-06-15 09:20 Kashgar	ware zonnetijd	zonder correctie Yi-Si, met correctie Gui-Mao

Een eerlijke opmerking over met wie we precies overeenkomen. De uitgever van de dataset schrijft dat zijn engine gebaseerd is op tyme4ts, en lunar-javascript van dezelfde auteur. De drie bovenste rijen van de tabel zijn dus één lijn, en geen drie onafhankelijke stemmen. Van de onafhankelijke implementaties heeft feng-shui-institute.org volledige dekking, en na het toepassen van de ware zonnetijd reproduceren we hun antwoord op alle drie de probes waar zij de correctie toepassen.

De enige echte afwijking met de school die we behouden, is de dagovergang om 23:00.