Case 07 of 26
Historical time zones
Beijing 1990: historical daylight saving applies
China observed daylight saving time on this synthetic summer date.
Boundary question
Does the engine use the historical +09:00 clock offset rather than modern +08:00?
Yes. IANA history supplies UTC+09:00 with a 60-minute DST component, and the corrected solar time becomes 10:45.
Synthetic input
Recorded facts
- Date
- 1990-06-15
- Recorded time
- 12:00
- Location
- Beijing, China
- Time zone
- Asia/Shanghai
- Longitude
- 116.4074°
- Gender input
- Male
Pinned expected facts
Verified output
Year
庚午
Month
壬午
Day
辛亥
Hour
癸巳
- Day Master
- 辛
- True solar time
- 1990-06-15 10:45
- Total correction
- -74.40 minutes
- Historical offset
- UTC+09:00 · DST 60 min
- Luck direction
- 顺排
- Reference Jie
- 小暑 · 1990-07-07 17:00:28
- Luck start
- 1997-11-16 16:29:36
Reading the boundary
What this case means for your own chart
China observed daylight saving time from 1986 to 1991. If you were born in a Chinese city during one of those summers, the clock time written on your record is probably an hour ahead of the standard time your chart should be built from. This case is a synthetic summer record from that window, and it is also the fixed example chart used elsewhere on this site.
The correction here is large. Starting from a noon clock reading, the historical UTC offset plus the daylight-saving component plus the longitude difference from the 120°E reference meridian plus the Equation of Time together move the true solar time to 10:45. That is seventy-four minutes of movement, which is more than an hour pillar in the wrong direction.
This is the single most consequential timezone fact for readers born in China in the late 1980s. A chart built from the raw clock reading will place an hour pillar that the corrected time does not support. The same record, run through the correction, may land in a different two-hour branch entirely.
Because this is also the chart we use on the sample-report page and in the Learn guides, you can follow the same four pillars through several different presentations on this site. That is useful if you want to see how a correction receipt, a chart display, and a written reading relate to one another before entering your own data. The chart is invented rather than drawn from any person's record, and the same four pillars appear here as a pinned test case so the example cannot silently drift.
Check your own record
- If you were born in China between 1986 and 1991, check whether your birth date falls inside that year's daylight-saving window.
- If it does, subtract the daylight-saving hour before doing anything else, then apply longitude and Equation of Time corrections.
- Do not assume your record is already in standard time just because it came from an official document. Official records log the clock that was on the wall.
Which convention is in play
- Calculation fact
- The pinned engine reads the historical offset from the IANA timezone database and returns UTC+09:00 with a 60-minute DST component for this input, correcting noon to 10:45 true solar time.
- Convention
- Applying true solar time before deriving the hour pillar is standard practice, but the specific correction pipeline varies between calculators. A tool that skips the historical offset is not applying a different school, it is applying fewer corrections.
- Our explanation
- The judgement that this is the most consequential timezone case for Chinese readers is ours, based on how large the correction is relative to an hour-pillar width.
Conventions and limits
What this case does — and does not — prove
It verifies
Deterministic reproduction of this input under the named engine version and conventions. A pinned-field mismatch stops the production build.
It does not claim
Universal agreement across Bazi schools, interpretation of a real person, or certainty where the historical record is incomplete.
tyme4ts 1.5.2 · cantian-tymext 0.0.27 · sect 2 day boundary · BaziCalculator.ai NOAA/IANA true-solar adapter
calculation-benchmarks-v1 · reviewed 2026-09-05