Designing a Birth-Time Form That Does Not Invent an Astrology Chart

A birth-chart form appears to need only three inputs: date, time, and place. But those fields contain several decisions that can change the result. If the interface hides those decisions, it can produce a confident-looking chart from an incorrectly interpreted birth record.

Keep the local time and the place together

“04:10” is a clock reading, not a universal timestamp. The same instant may appear as 04:10 in Jakarta and 05:10 in Singapore. If someone was born in Jakarta, they should be able to enter the time recorded there and select Jakarta as the birthplace. The application should handle the time-zone conversion.

Asking users to convert their birth time to another city first creates an easy mistake: they may enter the converted time while still selecting their original birthplace, causing the application to convert it again.

A useful data model keeps the original local date and time, the birthplace, and the resolved time zone separate. That also makes it possible to show users which assumptions were used.

Use the rules from the birth date

A place's current UTC offset may not be the offset it used decades ago. Daylight saving rules have changed, sometimes more than once. A birth-chart calculator needs the time-zone rules that applied at the birthplace on the birth date.

The interface should also handle uncertainty honestly. If a historical local time cannot be resolved unambiguously, ask for clarification or show the uncertainty. Silently choosing an offset makes the chart look more certain than the input allows.

Unknown is a valid input state

Many people do not know their birth hour. Replacing a blank field with noon or midnight may make a form easier to process, but it changes the chart.

For BaZi, the year, month, and day pillars can still be shown while the hour pillar remains unknown. For Zi Wei Dou Shu, the missing hour affects the palace layout more substantially. In either case, the UI should explain what can be calculated and leave the rest unresolved.

Make calendar boundaries visible

Time zones are only one source of disagreement between calculators. In BaZi, the year pillar changes at Li Chun, around the beginning of February, rather than on January 1 or necessarily on Lunar New Year. The month pillar follows solar terms.

For a birth close to one of these boundaries, a short note beside the result can explain which rule the calculator used. That is more useful than presenting two different charts as though one must be a software error.

We apply these principles in the fatequery BaZi calculator: the chart is calculated from the birth details first, and an AI-assisted reading explains the chart shown on screen. A follow-up question does not need to generate a new chart.

The broader design lesson applies beyond astrology. When an application turns local time into a rule-based result, preserve the original input, expose consequential assumptions, and allow unknown information to remain unknown.