The Hidden Piece of True Solar Time: The Equation of Time and the BaZi Hour Pillar

Many BaZi chart-casting implementations perform a "true solar time" correction, but the vast majority do only half of it — they convert the clock's civil time into local longitude time, yet drop the other half: the equation of time. That missing part can reach -14 to +16 minutes over the course of a year, and for an hour pillar bounded in two-hour blocks, that is enough to push a person's hour pillar into the one next door. This piece breaks down the two-step correction for true solar time, and why the second step is the one most easily overlooked.

What True Solar Time Actually Is

The time on the clock is "civil time": everyone in a time zone shares the moment of a single standard meridian. But the sun does not recognize administrative boundaries. To recover "the exact moment the sun is truly directly overhead," you have to make two corrections on top of civil time:

• Longitude correction: convert the standard meridian's time to the local mean time at your longitude.
• Equation of time (EoT): correct the "mean sun" time into the "true sun" time.

Summed up in a single formula:

true solar time = civil time + longitude correction + equation of time

The common mistake is to do only the first two terms and treat that "local mean time" as if it were "true solar time."

Step One: Longitude Correction (Relatively Easy to Get Right)

Earth rotates 15 degrees per hour, which works out to 4 minutes for each degree of longitude. So the time correction from the standard meridian to the actual birthplace is:

longitudeCorrection = (longitude - standardMeridian) × 4   # minutes, 4 minutes per degree

The only trap here is how to pick standardMeridian (the standard meridian). It should be determined by that location's standard time zone offset for the relevant year, and the standard time zone offset must strip out daylight saving time (DST) — DST just moves the clock forward; it doesn't change the sun's position. The stripping logic is usually:

standardOffset  = secondsFromGMT(date) - dstOffset(date)
standardMeridian = standardOffset / 3600 × 15

As long as DST is stripped correctly, this step gives stable, correct results across hemispheres and across the various summer/winter boundaries:

Notice that Sydney converges to 150°E in both summer and winter, New York still takes 75°W under DST, and London still takes 0° under DST — that is precisely the sign that DST has been stripped correctly. The longitude correction step is not hard mathematically; the difficulty is that it gives you the illusion that "I've already finished true solar time."

Step Two: The Equation of Time That Gets Dropped

The "mean sun" is an imaginary sun that moves at a constant rate; the real sun, because Earth's orbit is elliptical (faster near perihelion, slower near aphelion) and because of the obliquity of the ecliptic, does not move at a constant rate. The time difference between the true sun and the mean sun is the equation of time.

It is a periodic quantity that depends only on "which day of the year it is," fluctuating between roughly -14 and +16 minutes over the year:

A commonly used approximation (with N as the day of the year) is:

B   = 2π × (N - 81) / 365
EoT ≈ 9.87·sin(2B) - 7.53·cos(B) - 1.5·sin(B)   # unit: minutes

This approximation is already good enough for the precision needs of chart casting. If you're after astronomical-grade precision, you can switch to a higher-order expansion, but it makes no material difference at the magnitude discussed here.

Why It Is a "Fatal Flaw" for the BaZi Hour Pillar

The BaZi hour pillar is bounded at two-hour intervals (the zi hour, the chou hour, and so on — modern practice commonly uses 23:00 / 01:00 / 03:00 … as the boundaries). This means any error that pushes the birth moment toward or away from an on-the-hour boundary can change where the hour pillar lands.

And the equation of time is on the order of ±16 minutes — that one term alone is enough to cross a boundary. Here is an example that points to no real individual: someone born around the wu hour, with a clock time falling in the 11:40 to 12:20 range. If the chart casting does only the longitude correction and ignores EoT, then in the months of the year when EoT is large, the corrected true solar time could slide from "early wu" to "late si," or the other way around — the hour pillar is off by a full pillar, and everything downstream that builds on the hour pillar shifts with it.

Three Engineering Traps That Are Easy to Fall Into

1. Using "current time" vs. "birth time" to compute the time zone

A common pattern is to use now() (the moment the program runs) to look up the time zone offset, rather than the birth date. Most of the time this "happens" to be correct, because after stripping DST the standard meridian usually doesn't change from year to year. But once a location's historical time zone rules have changed, using the current time produces a wrong answer. The correct approach is to always use the birth date to query the time zone and DST status for that year.

2. Historical DST boundaries

China observed daylight saving time from 1986 to 1991 (clocks moved forward one hour from April to September each year). An operating system's time zone database may not recognize this history day-for-day at the start and end boundaries the way the official announcements did. For records in this period, and specifically for births between May and September, the safe approach is to prompt the user in the interface — "DST was in effect during this period; please confirm you are entering clock time" — rather than silently processing it under one particular interpretation.

3. An incomplete longitude database "fails silently"

If the chart casting relies on a built-in table of city longitudes, and that table covers only a handful of large cities, then locations outside the table will often fall back to "no correction." The most dangerous thing about this kind of error is that it throws no error and gives no warning — the user has no way of noticing at all. Either make the longitude database complete (covering at least the major population centers), or allow entering latitude and longitude directly, and give a clear warning whenever the fallback kicks in.

The Complete Algorithm, Corrected

Putting the two corrections together, a language-agnostic implementation skeleton looks like this:

function trueSolarTimeOffset(longitude, timeZone, birthDate):
    tzOffset          = secondsFromGMT(timeZone, birthDate)
                        - dstOffset(timeZone, birthDate)     # strip DST
    standardMeridian  = tzOffset / 3600 × 15
    longitudeCorrection = (longitude - standardMeridian) × 4  # 4 minutes per degree
    return longitudeCorrection + equationOfTime(birthDate)

There is only one key change: the function signature must carry the birth date as a parameter — EoT depends on it, and the historical time zone lookup depends on it too. This change propagates all the way along the call chain; everywhere that gets the birth moment has to pass the date through. It looks like just adding one parameter, but in reality it upgrades "true solar time" from a half-finished piece into a complete implementation.

Summary

Of the two corrections in true solar time, the longitude correction is straightforward and easy to get right — and that is exactly what makes it misleading, because it lets people believe the work is done. What really decides success or failure is that equation of time — only a dozen-odd minutes, yet enough to cross an hour-pillar boundary. For any chart-casting system rooted in the "birth moment," dropping EoT is not a precision issue; it is a structural defect that can change the conclusion.