Case 08 of 26
Historical time zones
Chicago 1990: western longitude plus DST
A North American historical record exercises a negative UTC offset and summer time.
Boundary question
Can the same wall-clock noon be normalized with America/Chicago history?
Yes. The record uses UTC−05:00 with a 60-minute DST component and corrects to 11:09 true solar time.
Synthetic input
Recorded facts
- Date
- 1990-06-15
- Recorded time
- 12:00
- Location
- Chicago, United States
- Time zone
- America/Chicago
- Longitude
- -87.6298°
- Gender input
- Female
Pinned expected facts
Verified output
Year
庚午
Month
壬午
Day
辛亥
Hour
甲午
- Day Master
- 辛
- True solar time
- 1990-06-15 11:09
- Total correction
- -50.55 minutes
- Historical offset
- UTC−05:00 · DST 60 min
- Luck direction
- 逆排
- Reference Jie
- 芒种 · 1990-06-06 06:46:18
- Luck start
- 1993-07-07 09:27:27
Reading the boundary
What this case means for your own chart
This is the same calendar date as the previous case, but not a different hemisphere: Beijing and Chicago are both north of the equator. The meaningful contrast is longitude and offset direction. Chicago in June 1990 runs on UTC−05:00 with daylight saving, so its longitude correction runs in the opposite direction from the Beijing case and is smaller in magnitude.
The pair is useful because it separates two things readers tend to merge: the daylight-saving component and the longitude component. Both cases carry a sixty-minute DST component, but Beijing corrects by seventy-four minutes and Chicago by fifty-one. The difference is longitude, not policy.
For a reader born in North America, the practical takeaway is that the DST question and the longitude question are separate, and both must be answered before the hour pillar can be trusted. A chart that handles DST but ignores longitude will still be off by tens of minutes near a boundary.
A further detail specific to North America is that daylight-saving rules changed several times over the twentieth century, and some regions adopted them late or dropped them entirely. The historical offset for a given date therefore cannot be inferred from what the rule is today. It has to be looked up for that place and that year, which is what the timezone data underlying this case provides.
Check your own record
- Confirm whether your birth date fell inside daylight saving for your location in that year, using the historical rules rather than today's.
- Apply the longitude correction for your birth city against the standard meridian of your timezone, not against your country's capital.
- Treat the two corrections as independent. Getting one right does not compensate for skipping the other.
Which convention is in play
- Calculation fact
- The pinned engine returns UTC−05:00 with a 60-minute DST component for this Chicago input, correcting noon to 11:09 true solar time.
- Convention
- How large a longitude correction to apply, and against which reference meridian, is a convention question. This engine states its reference and applies it consistently.
- Our explanation
- Framing this case as the counterpart that isolates longitude is our presentation choice. The two cases were not originally designed as a matched pair.
Related reading
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