skills/ziwei-timing/references/profile-setup.md

# Date and time clarification

Read only when the supplied profile information needs normalization or clarification. Ordinary setup starts with a Gregorian/Common Era date; it does not introduce lunar months or leap rules.

- A clearly identified era can be converted when its calendar and conversion are reliable. For example, explicitly stated ROC year 80 corresponds to CE 1991; modern Thai Buddhist Era 2543 corresponds to CE 2000. A Japanese era also requires a valid date within that era. Do not apply a numeric offset to a bare short year or assume a historical Buddhist calendar follows the modern rule. If the conversion cannot be established, request the Gregorian date or clarify only the ambiguous component.
- Show the original era/calendar and resulting Gregorian date when reviewing a conversion. Let the normalized server preview validate the resulting date, timezone and DST resolution; never bypass a validation error with a guessed replacement.
- If the user explicitly supplies a lunar date, preserve lunar input rather than pretending it was Gregorian. Clarify Chinese lunisolar versus another lunar calendar only when unclear. Ask whether it is a leap month only if needed to identify that date; do not silently turn an ambiguous lunar date into a non-leap date. If an actual leap month is used, show the service's returned leap-month handling in the confirmation. Do not ask ordinary solar-date users about it.
- Unknown exact minutes are acceptable if the user knows a supported shichen; do not manufacture a clock time. An ambiguous Zi hour needs its early/late civil-day side clarified. If neither exact time nor shichen is known, do not insert a guessed time into ordinary setup. Only an explicit request to help estimate it enters the dedicated [birth-time interview](birth-time-rectification.md). Otherwise ask for the missing information without guessing or automatically starting an interview.
- Birth timezone describes the birthplace's historical civil clock. Residence timezone controls current and period readings; a move does not change birth timezone. A city is sufficient only when its IANA mapping is unambiguous. A fixed UTC offset is not a replacement for historical timezone rules.
- A returned DST gap requires a corrected input. A fold requires the user's choice between the two possible instants; explain the local clock ambiguity without choosing for them.

These clarifications do not authorize a write. Every complete candidate still requires the skill's normalized preview and a later explicit confirmation before commit.

An incomplete `preview_profile_change` is not a server-side draft. On `readyToConfirm:false`, keep the complete accumulated patch from this setup/edit in the current conversation, ask for the returned missing information, and send the whole accumulated patch plus the new fields to the next preview. Existing saved fields may remain unchanged; do not fetch their birth data merely to rebuild an edit. Do not treat a prior incomplete preview as storage, resend only the latest answer, or invent fields that were never supplied. Commit still sends only the confirmation ID from the final complete preview.