How to Verify a Zi Wei Dou Shu Chart
When two tools disagree, audit layers from source input to school rules instead of declaring one defective immediately.
Layer 1: source record
- Contemporaneous record or memory?
- Gregorian or lunar?
- Leap month?
- 12- or 24-hour time?
- Correct city?
Layer 2: time rules
Check historical zone, DST, true solar time, and day-change rules. Change only one parameter at a time.
Layer 3: calendar conversion
Cross-check the converted Gregorian date with a reliable independent calendar. If this differs, later comparisons are premature.
Layer 4: school parameters
- Leap-month method.
- Palace and stem derivations.
- Transformation tables.
- Brightness tables.
- Decadal and nominal-age rules.
Comparison template
| Item | Tool A | Tool B |
|---|---|---|
| Calendar input | ||
| Converted date | ||
| Time zone/solar time | ||
| Hour/day change | ||
| Life/Body Palace | ||
| Transformation rules |
Worked audit example
Suppose the source record says “June 15, 1990, 23:10, Chengdu.” Tool A uses Beijing civil time unchanged, while Tool B applies true solar time. Chengdu is approximately 104.1°E, about 15.9 degrees west of China’s 120°E standard meridian. The longitude component alone is therefore about 15.9 × 4 = 63.6 minutes earlier. After adding the date-specific equation of time, the corrected time may remain in the 22:00 hour. The tools can consequently select different traditional hours and, under some rules, different chart dates.
To find the cause, save the original input, disable every optional correction, and create a baseline chart. Then enable one setting at a time. If the first difference appears when true solar time is enabled, do not compare star interpretations yet: compare the corrected timestamps and boundary rule first.
Six-step reproducible checklist
- Transcribe the source record without silently “correcting” it.
- Identify Gregorian, lunar, and leap-month status.
- Verify the legal UTC offset and daylight-saving rule for that date and place.
- Record whether solar correction is enabled and its resulting timestamp.
- Record the 23:00 day-change, leap-month, and transformation-table rules.
- Export both charts and mark the earliest calculation layer that differs.
Input difference or software defect?
If identical inputs, versions, and declared rules still produce different calendar conversions or palace positions, preserve a minimal reproducible report: every input value, enabled options, browser, generation time, and screenshots. A difference that follows a named option is usually a definition or configuration issue; a difference that persists under identical conditions is suitable for a defect report.
Practical questions
Should two websites always produce the same chart?
No. Agreement is expected only when calendar conversion, legal time, location correction, day boundary, leap-month treatment, and school tables are the same. A useful comparison lists those settings instead of comparing screenshots alone.
Which result should I trust first?
Trust the result with the clearest audit trail: preserved source record, declared conversion, named software version, and reproducible options. A more confident interpretation is not stronger calculation evidence.
What should I send when asking for help?
Send the source type without unnecessary personal identifiers, the exact calendar and time inputs, birthplace at city level, enabled options, two result screenshots, and the first field that differs. Avoid sending identification numbers or a full birth certificate.
Conclusion
Verify input, time, calendar, school, then interpretation—in that order. Save the settings with every chart so a later update can be compared without reconstructing assumptions from memory.
Sources and editorial note
Written and editorially reviewed by the StarDestiny AI editorial team; updated August 10, 2026. The workflow was tested against this site’s iztro 2.5.8 implementation and references the IANA Time Zone Database for historical offsets and the Chinese Astronomical Ephemeris for calendrical concepts. The example demonstrates debugging, not scientific validation of astrology. See our editorial and testing standard.