When people audit a BaZi chart, the “hour problem” is often really a day-change problem. The rat double-hour (子时) roughly covers 23:00–01:00. The usual dispute is not whether the label is “rat,” but which stem-branch day that hour belongs to.
If the day is wrong, the day pillar changes; when the day pillar changes, the hour’s assignment story changes with it. Treating 子时 as “hour pillar only” is not rigorous.
Separate two questions
| Question | What it asks |
|---|---|
| Day change | Which day pillar (which stem-branch day) contains this instant? |
| Double-hour | Within that day, which hour pillar applies? |
They interact, but they are not the same layer. Transparent tools should state each rule — not hide behind “handled traditionally.”
Why “early / late rat” talk exists
In folk and school practice you will meet habits such as (names vary; the rule matters):
- Mapping 23:00–24:00 to the previous civil day or to the next stem-branch day
- Using midnight (00:00) as a hard cut, sometimes with finer 子初 / 子正 splits
If two apps fork silently here, the same clock time can yield different day pillars, or the same day pillar with a different hour pillar. Align day-change policy before comparing all four pillars.
This article does not crown one school as uniquely correct — that is outside intro scope. The product rule is: whichever fork the engine uses must be written down and recomputable.
A check you can run without memorizing mnemonics
Take a birth near 23:30 on a known civil date (substitute your own):
- Freeze timezone and whether true solar time is applied
- Ask tool A for day pillar and hour pillar
- Ask tool B the same
- If day pillars already differ: stop at day-change rules; do not jump to luck-cycle arguments
- If day pillars match and only hour pillars differ: then inspect the double-hour table and rat-hour splits
After policies match, the day pillar remains a strong anchor. Rat-hour samples are the stress test — they expose unpublished day-change forks.
Compared with midday births: noon-ish samples are good for ordinary day-pillar table checks; rat-hour samples are good for checking whether boundaries were disclosed.
Timezone and true solar time
Day-change disputes often stack with:
- Timezone / local clock: is the input local civil time, or already converted?
- True solar time: longitude / equation-of-time style corrections can push an instant across a boundary
When none of the three is disclosed, two apps can each be “correct on their own stack” while looking random to users. See How to verify a BaZi chart and What is the day pillar?.
Minimum disclosure for a transparent product
Help text or chart metadata should state at least:
- How the rat-hour window is defined (and whether it is split)
- Which stem-branch day 23:00–24:00 belongs to by default
- Whether users can switch day-change options (if yes: reproducible and exportable)
- The order of composition with timezone and true solar time (correct time first vs change day first)
Daovian’s method commitment: calculation stays in the engine; boundaries are rules — a model must not “feel” which day you were born on. See Method and BaZi.
Short take
The core sentence for 子时: ask which day first, then which hour.
If the day pillar moves, it is not a tiny hour typo — the day’s anchor moved. Tools that can say this clearly are the ones allowed to claim transparent charting.