The direct answer
A chart calculation must convert local civil time into UTC.
A birth record gives local clock time. To calculate astronomical positions and angles, software must resolve the birthplace and the historical UTC offset in effect there on that date. Modern timezone rules cannot simply be projected backward.
The clock on a birth record is not yet astronomical time.
Useful context
The conversion should be preserved with the chart.
Places change names and boundaries; governments change offsets and daylight-saving rules. A versioned profile should retain the selected location, coordinates, timezone identifier, resolved offset, and timezone-data version so the result can be reproduced or corrected.
See the methodology
Connect this idea to a representative profile preview.
A practical framework
Four ideas to keep in view.
- Resolve placeMap the user’s birthplace to reviewed coordinates and an IANA timezone.
- Resolve historyUse the rule that applied on the birth date, including daylight-saving exceptions.
- Convert to UTCCreate one unambiguous astronomical timestamp before calculating placements.
- Keep a recordStore versions and inputs so later corrections do not silently rewrite the chart.
Common questions
Questions to ask before trusting a result.
Can a one-hour timezone error change the chart?
Yes. It can noticeably shift the Ascendant, Midheaven, houses, and the Moon’s exact position. Near a boundary, the displayed sign or house may change.
Does daylight saving time affect a birth chart?
Yes. Software must use the daylight-saving rule that applied at the birthplace on the birth date. Assuming a modern rule or applying daylight saving twice can shift the chart by an hour.
Why do old birth dates need special timezone handling?
Offsets and local rules changed over time, sometimes because of regional or political decisions. Historical timezone data is needed to convert the recorded local time into the correct UTC instant.