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
Numbers from a worked example are illustrative, not precedent. Run yours, keep the inputs beside the result, and confirm any rule that carries a consequence.
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
These cover the calculations described above. Every page shows its method, so a result can be checked rather than taken on trust.
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.