How to avoid double DST correction in a BaZi calculator

If two BaZi calculators disagree near an hour boundary, a daylight-saving adjustment may be part of the explanation. But “subtract one hour and try again” is not a universal fix. You first need to know which clock convention each calculator expects. Otherwise, a well-intended correction can change the input twice.

Start with the recorded clock time

Keep an unchanged copy of the date and local civil time written in the birth record, together with the birthplace and any stated time-zone information. Local civil time means the clock reading in use there at that moment. Do not silently replace it with UTC, today's offset, Beijing time, or a guessed standard-time value.

Next, read the calculator's input instructions. Does it accept recorded local time and resolve historical time-zone and DST rules automatically? Does it explicitly request local standard time? Or does it ask you to choose an offset or a DST setting? Those interfaces require different inputs. If the convention is unclear, seek clarification before changing the record.

Where double correction happens

Here is a fictional arithmetic example, not a birth chart: a record says 10:30 during a period when the applicable daylight-saving adjustment was one hour. A tool explicitly requesting standard time might require 09:30 under its documented convention. A tool expecting recorded civil time still needs 10:30. Entering 09:30 into that second tool may make it resolve an already altered clock reading, applying the adjustment twice.

This example does not establish that every calculator removes DST from its BaZi clock. Historical time-zone validation and the clock used to calculate the pillars are separate policy choices. Nor are all historical clock changes one hour. Python's official zoneinfo documentation illustrates date-dependent time-zone offsets and DST transitions; check the place and historical date rather than using the city's current offset.

Keep solar time and clock changes separate

True solar time is another calculation convention. Check whether it is enabled and how the tool describes it. Do not stack a solar-time adjustment on top of a DST adjustment just to make two charts match. Compare one documented setting at a time, including the tool's day-boundary rule when the time is close to midnight.

A backward clock change can make the same local time occur twice. A forward change can leave a clock time that never occurred. The official PEP 495 explanation describes these repeated and missing times. A repeated time needs evidence about which occurrence or offset applies; a missing time needs the record checked. Selecting whichever option gives a preferred chart does not resolve the uncertainty.

One clock time, two instants: see New York’s two 01:30 occurrences on 3 November 2024.

A practical final check

Write down the original record, each tool's expected input, the historical time-zone handling, and any solar-time setting. If the birth time is unknown, keep it unknown; noon or midnight is not a factual substitute. Consistent inputs help explain differences, but do not establish the predictive validity of BaZi.

We are the YUVYN team. Our birth time and birthplace guide explains our current policy: recorded local clock time, historical time-zone checks, and no true solar time correction. When your recorded time is known, you can generate a free BaZi chart in English and compare the chart labels alongside those input conventions.