Missing and Repeated Local Times During DST
Handle nonexistent and repeated local birth times during daylight-saving transitions without guessing the Bazi hour or date.
Overview
A forward clock transition creates a gap: some local clock readings never occurred. A backward transition creates an overlap: one reading occurred twice with different UTC offsets. Although a one-hour change is familiar, historical transitions can use other amounts, so the exact birthplace, date and IANA time-zone rule must decide the case. OpenFate rejects nonexistent inputs and preserves both candidate instants for an unresolved overlap instead of silently choosing one.
At a glance
- Forward transition
- Creates local times that did not occur
- Backward transition
- Repeats local times with two offsets
- Required resolver
- Birthplace, date and IANA zone
- Unsafe default
- Automatically moving to the nearest valid time
- Possible impact
- Hour, day or solar-term boundary
- Safe output
- Correction request or two labeled candidates
A forward transition can make the recorded wall time impossible
When a legal clock jumps ahead, every display inside the skipped interval is nonexistent in that zone. The familiar spring transition is one example, but the size and date of the jump are historical facts, not universal constants.
The calculator should identify the gap and ask whether the source time was copied incorrectly or recorded under another convention. Moving it forward automatically fabricates a different birth instant.
- Validate the local reading against the historical zone.
- Do not repair a gap without user evidence.
A backward transition can map one wall time to two instants
When clocks move back, the repeated interval first occurs under the earlier offset and then under the later offset. Both candidates share the same written local time.
If a certificate does not record the offset or which occurrence was intended, preserve both. Compare whether they produce distinct solar times or pillars before asking for additional evidence.
- Retain both effective offsets.
- Label first and second occurrence clearly.
Only crossed calculation boundaries change the chart
Resolve each candidate instant, apply the selected solar-time setting, and then test the hour branch, day boundary and exact solar-term instant.
A DST ambiguity does not automatically mean two different charts. If both candidates remain in the same pillar intervals, report the chart as stable while keeping the unresolved provenance.
- Deduplicate identical candidate charts.
- Name the boundary that causes any difference.
Daylight-saving rules must come from the date, not memory
A place may adopt, suspend or change daylight-saving rules across years. Today’s rule, a browser default or the assumption “summer means DST” cannot establish a historical offset.
Save the zone identifier, database version, candidate offsets and resolution decision. This is a time-conversion issue, not evidence of fortune, disruption or personality.
- Use versioned historical rules.
- Make no symbolic claim from a clock transition.
Sources and editorial basis
- NIST: Daylight Saving Time (DST)NIST 說明標準時間與日光節約時間的撥鐘制度，向前與向後轉換會造成當地鐘錶讀數的不連續The U.S. timekeeping authority’s explanation of daylight-saving clock changes and the distinction between standard and daylight time.
- IANA: Theory and Pragmatics of the Time Zone DatabaseIANA theory 定義歷史時區轉換與有效偏移；缺口讀數沒有對應瞬間，重疊讀數則可對應兩個不同瞬間The IANA reference for time-zone identifiers, historical coverage, aliases, offsets, transitions, and known limits of the database.
- OpenFate Editorial Methodology產品拒絕不存在時刻，對未消歧的重複時刻保留兩個候選，只在候選跨過時辰、日界或交節時報告四柱差異OpenFate separates deterministic chart calculation, traditional interpretation, and modern editorial explanation.