UTC and UTC Offsets in Bazi
Understand how UTC and numeric offsets identify a birth instant, why an offset is not a time zone, and how this affects Bazi boundaries.
Overview
Coordinated Universal Time (UTC) provides the common timeline reference used to compare local times. A numeric UTC offset, such as +08:00 or −05:00, states how one local reading relates to UTC at that moment. It does not contain the location’s historical transition rules and therefore cannot replace an IANA time-zone name for an ordinary birth record. OpenFate resolves the historical zone first, stores the resulting instant and offset, and only then applies declared Bazi boundary rules.
At a glance
- UTC
- Common timeline reference
- Offset format
- Signed difference such as +08:00
- Offset limit
- No historical transition rules or place identity
- Zone role
- Derives the correct offset for place and date
- Stored result
- Resolved instant plus effective offset
- Bazi role
- Prevents false day and hour boundaries
UTC and a local offset identify one timeline instant
RFC 3339 represents a local date and time together with a numeric offset from UTC. Subtracting a positive offset or adding the magnitude of a negative offset yields the corresponding UTC reading.
For example, 08:00+08:00 and 00:00Z describe the same instant. They do not describe the same local calendar context for Bazi until a location and the chosen boundary method are also known.
- Keep the sign and minutes exactly.
- Distinguish the instant from its local display.
A UTC offset is a result, not a complete time-zone rule
Many regions can share +08:00 today while having different historical rules. One region can also use several offsets across its history because of daylight-saving time or legal changes.
A fixed offset is sufficient only when the source explicitly gives that offset for the event. For place-and-clock input, use an IANA zone to derive the date-specific offset.
- Do not infer a city from an offset.
- Do not apply today’s offset to an old date.
Resolve the instant before testing Bazi boundaries
The local record, birthplace and historical zone first determine the UTC instant. The calculator can then reconstruct the configured local or solar time used for solar terms, hour branches and day rollover.
Reversing that order can shift the chart by an hour or a date near a transition. The final page should show the effective offset and zone identifier so the result can be reproduced.
- Zone resolution precedes pillar assignment.
- Expose the effective offset in provenance.
Unknown and zero offsets must not be conflated
RFC 3339 distinguishes a known UTC reading from a local time whose offset is unknown. A missing offset cannot safely be treated as +00:00.
If the birthplace or zone is unresolved, the chart should request clarification or remain uncalculated. Guessing UTC can silently change the date, solar-term side and Hour Pillar.
- Do not turn missing offset into UTC.
- Fail closed when the instant is ambiguous.
Sources and editorial basis
- IETF RFC 3339: Date and Time on the InternetRFC 3339 定義本地日期時間、Z 與數值 UTC 偏移的時間戳語義，並區分未知偏移與已知零偏移The IETF timestamp standard defining UTC notation, numeric UTC offsets, local date-time fields, and the meaning of an unknown local offset.
- 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產品先將出生地民用時刻解析為 UTC 瞬間及有效偏移，再以指定本地或太陽時規則判斷四柱邊界OpenFate separates deterministic chart calculation, traditional interpretation, and modern editorial explanation.