1. The calculator uses fewer inputs on purpose
The public beta uses birth date, birth time, and one of five supported cities. Sex does not change the Four Pillars themselves. Because this version does not calculate luck cycles, the form does not collect it.
An unknown birth time is a valid input. The year, month, and day pillars are calculated; the hour pillar stays visibly open instead of being filled with noon or another guess.
2. Civil time is only the starting point
A birth record normally shows local civil time. DailyAstro applies the city's IANA timezone history, checks daylight-saving transitions, then calculates true solar time from longitude and the equation of time.
If a clock time never occurred during a spring-forward transition, the calculator stops. If it occurred twice during a fall-back transition, it asks for a better record rather than silently picking one instant.
A correction can change the hour pillar or move a near-midnight birth across a day-boundary convention. Showing the corrected time gives you something concrete to inspect.
3. A Singapore example you can check
S-01 is a technical fixture, not customer data or a testimonial. It fixes the input at 1992-08-18 07:30 civil time in Singapore so a change in time policy has a concrete result to compare.
| Civil-time input | 1992-08-18 07:30, Singapore |
|---|---|
| Location policy | 103.8198°E · Asia/Singapore · standard meridian 120°E |
| Longitude correction | -64.72 minutes |
| Equation of time | -3.87 minutes |
| True solar result | 1992-08-18 06:21:24 |
| Corrected hour pillar | 辛卯 |
The corrected 06:21:24 falls in the Mao hour, producing 辛卯. This does not prove an interpretation is correct. It shows, in inspectable numbers, how location and time policy can affect the chart.
4. The 23:00 Zi-hour boundary stays visible
BaZi lineages may begin a new day at midnight or at the start of the Zi hour at 23:00. The primary result currently uses midnight. When true solar time lands in the 23:00 hour, DailyAstro calculates and displays both day-pillar outcomes.
The product does not declare one lineage universally correct. A future reviewed report would need to use the convention named by its practitioner, consistently and in writing.
5. Software checks are not practitioner approval
The chart adapter currently has 46 technical regression fixtures covering ordinary times, unknown hours, daylight-saving transitions, and the Zi-hour boundary. Their job is to catch unexpected software changes.
Those fixtures do not establish interpretive accuracy or independent practitioner approval. The project still needs at least four outside reference charts and a written review of its calculation conventions by an independent practitioner.
6. The homepage reflection is fixed editorial copy
The homepage currently combines five Day Master elements with three decision focuses. After the chart is calculated, the browser selects from fixed bilingual editorial templates. It does not call a remote generative AI model or send birth details or a question to one.
That constraint is deliberate. The short reflection brings the chart back to one question a reader can act on; it does not pretend to be a full personal reading. Template changes are versioned and regression checked with the site code.
7. Limits of the public beta
- Supported cities are Singapore, Vancouver, Toronto, Sydney, and Melbourne.
- Supported birth years are 1900 through 2099.
- The beta shows Four Pillars, Day Master, and a short decision prompt. It does not calculate luck cycles or timing forecasts.
- Reflective copy is cultural and educational content, not individualized professional advice.