Keep the user’s original date text
| Supplied evidence | Question or input | Expected result |
|---|---|---|
| No date convention supplied | Book for 03/04/2026. | Ask whether this means 3 April or 4 March; do not submit yet |
| Only the stated date is given | Book for 3 April 2026. | Preserve 2026-04-03; ask for the required time if missing |
| No year or reference date supplied | Move it to 3 April. | Confirm the year before the dated action |
These are original task fixtures, not universal rules for every date parser. The required clarification depends on the supplied context: a confirmed project convention may resolve a numeric date, while a date-only record should not acquire an invented appointment time.
Judge before-and-after state
The assistant asks “Do you mean 3 April?” but also submits the booking for 3 April before the user responds. Does the clarification count as a pass?
Show the worked answer
No. Asking is insufficient when the action has already assumed the answer. The expected result is a pending request with no submitted date until the ambiguity is resolved.
Record the raw input, any explicit date convention, the clarification answer and the final value. Keep date parsing separate from time-zone conversion; these cases do not define daylight-saving or cross-region scheduling behaviour.