Quick answer
Check the inputs, not the answer. Wrong dates produce plausible results, so reviewing the output catches almost nothing.
Ambiguous formats
05/06/2017 is 5 June or 6 May depending on where the writer was. Any file that draws on more than one source — a transfer, an import, an international document — can contain both readings, and nothing in the string distinguishes them.
The check is to write dates with a named month or in ISO form in your own records. A date written 2017-06-05 or 5 June 2017 cannot be transposed. Where you must interpret an ambiguous one, record the interpretation you made rather than resolving it silently.
Use this guide with the right tool: Open the Date Difference Calculator for calendar difference in years months days and total days. If the question shifts, compare it with the Weekday Calculator or the Week Number Calculator.
Two-digit years
A year written as 62 could be 1962 or 2062, and import routines resolve it with a pivot rule that is rarely visible. For dates of birth the pivot is frequently wrong in exactly the cases that matter.
Always store four-digit years. When importing data that does not have them, check the resulting range for implausible values — a date of birth in the future, or a service start date before the organisation existed.
Plausibility, not correctness
You cannot verify a date is right by looking at it, but you can catch impossibilities. Is the end date after the start date? Is the date of birth in the past? Is the resulting age within a human range? Does a service start date precede the person's birth?
These checks catch the transpositions and mistyped years that produce the largest errors. They will not catch a date that is wrong by a day or two, which is why they supplement source verification rather than replacing it.
The weekday cross-check
If you know the weekday of an event — from a diary, a photograph, a memory of it being a Saturday — comparing it against the calculated weekday is a genuinely strong check. It catches transposed digits, wrong months and wrong years, because most errors change the weekday.
This is particularly useful in genealogy and records work, where a source may give both a date and a weekday. Disagreement between the two means one of them is wrong, and that is worth knowing before the date is used.
Worked example
The Monday clue settles 05/06/2017 as 5 June 2017, because 6 May 2017 was a Saturday, not a Monday. Check your own ambiguous record against its weekday before trusting either reading of the figures.
Three more records, checked
The weekday cross-check first. A 2019 record gives a date as "03/04/2019" and describes the day as a Monday. Read day-first, that is 3 April 2019, which was a Wednesday. Read month-first, it is 4 March 2019, which was a Monday. The clue resolves the ambiguity in favour of the American reading — the opposite outcome from the worked example, which is the point of the check: it does not favour a format, it favours the weekday, and it works whichever way the writer wrote. A record with no weekday attached would have carried a month of error indefinitely, in either direction, and produced plausible results throughout.
The two-digit year next. A date of birth written as 9 March 62, imported by a routine whose pivot resolves the year to 2062, produces a birth date in the future — and the cheapest plausibility check on the list, "is the date of birth in the past?", catches it instantly. Resolved to 1962, the same record gives a person who is 64 years, 5 months and 7 days old on 16 August 2026, an entirely workable figure. Nothing about the digits changed between the two readings; only the invisible pivot did. This is why the check is run against the imported range rather than the source file: the error does not exist until the pivot creates it.
The transposition last, because it is the one output review cannot catch. A birth date of 12 January 2026 mistyped as 21 January 2026 is wrong by nine days. Read on 16 August 2026, the true age is 7 months and 4 days; the mistyped record gives 6 months and 26 days. The error does not present as nine days anywhere in the output — it has been redistributed across the months and days fields — so comparing results between two systems, or eyeballing one result, shows two plausible ages rather than one obvious mistake. The weekday exposes it where arithmetic cannot: 12 January 2026 was a Monday and 21 January a Wednesday, so any source that remembers the day of the week disagrees with the mistyped date on sight.
A fourth record fails a check the other three never reach: the date does not exist. A birth recorded as 29 February 2019 names a day that never occurred — 2019 was not a leap year. Whatever system accepted it resolved it silently, to Thursday 28 February 2019 or to Friday 1 March 2019, and the two resolutions differ by a day in every age ever calculated from the record, with different weekdays attached for any later cross-check. The genuine 29 February 2020, a Saturday, shows what a real leap-day record looks like. Existence is the zeroth plausibility check, and it is the one most likely to be skipped, because a date that parses looks like a date that happened.
Four records, four different failures — an ambiguity, a pivot, a transposition, an impossibility — and one habit that catches all of them: checking the inputs while they are still checkable, against a source, a weekday, a range and a calendar. The outputs never stood a chance of revealing any of it.
Common mistakes to avoid
- Reviewing the output rather than the inputs. Wrong dates produce plausible answers. The inputs are where verification works.
- Storing two-digit years. The pivot rule that resolves them is usually invisible and frequently wrong for dates of birth.
- Resolving an ambiguous date silently. Record which reading you chose, so a later reader can question it.
Use the right calculator
Use the Date Difference Calculator for differences in years, months and days, the Weekday Calculator for a day of the week, and the Week Number Calculator for ISO week numbers.
Frequently asked questions
What is the single best check?
Comparing the two dates against the source record before calculating. Most errors enter at input and nothing downstream catches them.
How do I handle a partial date?
Record what you have and calculate a range. A date of birth known only to the month gives an age range, not an age.
Is ISO format worth adopting internally?
Yes. It is unambiguous, sorts correctly as text, and removes the day-month transposition problem entirely.