03/04/2026 is two different dates, and the Philippines uses both.
Government forms and American-influenced business write month first: the 4th of March. Schools, invoices and anything touching Europe or Asia write day first: the 3rd of April.
A month apart, both real dates, and nothing in the string says which.
So it is a setting here, not a guess. The page says which reading it used and prints the other one beside it — a wrong guess is then visible rather than quietly passed along.
When one number is above 12, the question is settled — 21/09/2026 can only be the 21st of September. No warning is raised there, deliberately: a warning on every date is a warning nobody reads.
And nothing goes through JavaScript’s Date. It silently turns 2026-02-30 into 2 March. Here a day that does not exist is refused, not corrected.
Both, and that is the problem. The Philippines uses both conventions: government forms and American-influenced business write MM/DD/YYYY, while schools, invoices and anything touching Europe or Asia write DD/MM/YYYY. The two readings are a month apart and nothing in the string tells you which was meant. So this asks you which to use, says which it used, and prints the other reading beside it — a wrong guess is then visible rather than silent.
Whenever one of the numbers is above 12, because only one reading is possible — 21/09/2026 has to be the 21st of September. This raises no warning in that case, deliberately. A tool that warns on every slashed date trains you to ignore the warning.
ISO 8601 — 2026-09-21 — for anything stored, sent or filed. It sorts correctly as plain text, it means the same thing in every country, and no locale setting can change how it is read. Use a written month ("21 September 2026") for anything a person reads. Reserve the slashed forms for informal writing where both parties already share a convention.
It was expanded on the usual pivot: 00–49 becomes 2000–2049, and 50–99 becomes 1950–1999. That guess is right most of the time and wrong for a birth date in the 1940s, or anything dated past 2049 — so the page tells you when it has guessed. Write the year in full and the question does not arise.
Because an ISO week belongs to whichever year its Thursday falls in, not to the year printed on the date. 1 January 2027 sits in week 53 of 2026; 31 December 2024 sits in week 1 of 2025. That is correct and it is why the week is always shown with its year — quoting "week 1" without the year is how a report gets filed twelve months out.
Because correcting it would be guessing. JavaScript's own Date silently turns 2026-02-30 into 2 March, which means a typo in a form becomes a real-looking date nobody questions. Nothing here goes through Date — the parsing works on the string and refuses a day that does not exist in that month.
Runs entirely in your browser; nothing is transmitted. Nothing is parsed through JavaScript's Date, which applies the host's locale and silently turns 30 February into 2 March. A day that does not exist is refused, not corrected. Nothing you type here is sent to our servers — the calculation runs entirely in your browser.
