DEV Community

David Webb
David Webb

Posted on Originally published at acrosstar.com

Birth times are messy inputs: timezones, DST, and solar time

Title: Birth times are messy inputs: timezones, DST, and solar time

I thought the evaluation engine would be the hard part. I was wrong; timestamp normalization took longer.

A local civil-time reading has to account for historical daylight-saving changes, sub-hour offset adjustments, and longitude corrections before it can yield true solar time. Then come the edge cases: solar-term transitions, and the competing rules that flip a calendar day at 23:00 or midnight. Either choice can change the state initializer.

Now I treat each raw birth timestamp as unvalidated input and send it through a strict timezone transformation pipeline.

When building a software pipeline for this calendar system, the input stage is deceptively complex. A timestamp such as 01:30 is a statement about a civil clock, not the Sun's position. Civil clocks follow regional time-zone rules, whereas apparent solar time depends on the Sun's actual position, shifting with longitude and the equation of time.

I rely on the IANA Time Zone Database (zoneinfo) to handle historical offsets and daylight-saving transitions (DST). But historical coverage varies in accuracy, especially for dates prior to 1970. A location name alone is insufficient. To resolve an ambiguous timestamp, you need a date, a specific zone, and an explicit UTC offset or occurrence marker.

Take New York on November 7, 2021. At the end of daylight saving time, clocks fell back from 2:00 a.m. daylight time to 1:00 a.m. standard time. That means 01:30 occurred twice: once at UTC−4 and again at UTC−5. Without an explicit occurrence marker, a wall-clock reading cannot distinguish those two instants.

If a calendar method requires true solar time, additional adjustments must be chained together. First, you resolve the civil time-zone offset and DST. Next, you apply a longitude correction relative to the zone's standard meridian. Each degree of longitude shifts solar time by roughly four minutes. New York sits near 74° west, while Eastern Standard Time is based on a 75° west meridian, placing New York about four minutes ahead of standard clock time. Finally, the equation of time must be applied, which fluctuates by date and can shift the result by up to 16 minutes.

These minutes matter most near boundaries. The hour branch divides the day into 12 two-hour intervals, such as Zi from roughly 11 p.m. to 1 a.m. Because Zi begins at 11 p.m. (23:00), some conventions flip the calendar day at 23:00, while others wait until midnight. Because the hour stem is derived from the day stem, choosing 23:00 versus midnight flips both the day pillar and the hour stem. This is why two implementations receiving the same input date can yield different charts.

I am still unsure about which time-normalization convention is most faithful to historical practice: civil clock time, local mean solar time, or apparent solar time. I also wonder how to clearly expose uncertainty in old zoneinfo records without making the chart interface unreadable—a common challenge when surfacing historical data.

Not medical, legal, or financial advice. A cultural and cognitive framework for self-reflection; outputs vary by individual.

Top comments (0)