03/04/2026 can mean March 4 or April 3. Both are real dates. If a parser silently picks one, the output can look perfectly clean while being wrong by a month.
/date leaves that choice to the caller when the value doesn't settle it. Without a format, this input returns valid: false. The original string remains in date. Requested calendar detail stays null when the date cannot be resolved.
When you know the source uses month-first dates, pass format=mdy. Add deep=true for calendar components, included on every plan. This is an excerpt of that response:
GET /date/03%2F04%2F2026?format=mdy&deep=true
{
"date": "2026-03-04",
"valid": true,
"deep": {
"month_name": "March",
"day": 4
}
}
With format=dmy, the same input returns 2026-04-03. The parameter supplies information about the source format that the digits couldn't provide.
You don't always need it. 3/29/2026 has only one valid reading because 29 cannot be a month. An ISO date like 2026-03-04 already makes the order explicit. Two-digit years remain unresolved rather than choosing a century.
For a form, an ambiguous result is a reason to ask the person to clarify. For an import, use the format established by the file's source. A parser can check whether a calendar date is possible, but it can't recover context that never arrived with the value.