GEDCOM Fix

Finding and Fixing Impossible Dates in Your Family Tree

Death before birth, 200-year lifespans, a parent younger than their child — how impossible dates get into a GEDCOM file, and how to track them all down.

GEDCOM Fix Editorial TeamUpdated 3 min read

An impossible date is any date in a GEDCOM file that contradicts another date for the same person or the same family — a death recorded before a birth, a marriage recorded before either spouse was born, or a lifespan so long it's almost certainly a data-entry error rather than a documented fact. These are some of the easiest errors to introduce and some of the easiest to miss, because each date on its own looks perfectly normal — the problem only shows up when you compare two of them.

The four patterns that show up most often

Death before birth. Usually a transposition — 1 DEAT with a 2 DATE 1887 sitting on a person whose 1 BIRT 2 DATE reads 1897. The digits are just swapped.

Marriage before birth. A MARR date on a FAM record that predates the BIRT date of one of the spouses. This is common after a merge, when a marriage event gets attached to the wrong person with a similar name.

Child born before a parent, or too soon after a parent's death. If a CHIL's birth year is earlier than either parent's, or more than about nine months after a father's death, the family link is almost certainly wrong even though each individual record parses fine on its own.

Implausible lifespan. A birth-to-death span well past documented human limits — typically flagged past roughly 110-120 years — is usually a mistyped century (1798 read as 1898) or a merge that combined two different people who happen to share a name.

Where these come from

Most impossible dates trace back to manual transcription: someone reading a faded record or a relative's handwritten note mis-keys a digit, and nothing in a plain text editor catches it. OCR'd source documents are another common source — a "3" and an "8" look similar enough in scanned handwriting to swap silently. Merges are the third major cause: combining two people's records because they share a name can leave one person's birth date attached to the other's death date, producing a lifespan that never happened to any single individual.

Why these matter beyond looking odd

Beyond the obvious factual problem, impossible dates actively mislead any tool or person trying to reason about the tree. A pedigree calculation that assumes normal generational spacing will misplace a person's position in the family relative to others. If you're preparing a file for FamilySearch or another platform, a reviewer or automated check on the receiving end may flag or reject records with contradictory dates, which is a worse outcome than catching it yourself first.

Finding them without checking every date by hand

Comparing every birth date against every death date and every parent-child pair by hand isn't realistic once a tree has more than a few dozen people. The Validator runs this comparison automatically across the whole file, flags each contradiction with the individuals and dates involved, and gives you the line number so you can go straight to the source record. Contradictions that are always wrong (death before birth) are reported as errors; implausible-but-not-impossible spans are reported as warnings so you can use your own judgment on cases near the edge.

Fixing what you find

Once a contradiction is flagged, go back to whatever source you transcribed the date from — a census record, a family bible, a relative's notes — rather than guessing a "close enough" replacement. If the original source itself is uncertain about the exact date, use a GEDCOM date qualifier (ABT 1850, BEF 1900) instead of inventing false precision; see GEDCOM Date Qualifiers Explained for the exact syntax. If you can't resolve a date at all, it's better to remove it and note the uncertainty in a NOTE than to leave a value you know is wrong.

Do it now

Keep reading

Common questions

Why is an implausible age a warning instead of an error?
Because it's a judgment call, not a structural fact. A death recorded 105 years after a birth is unusual but not impossible — a small number of documented cases exceed it. A death recorded before a birth, by contrast, is never correct. The Validator reserves 'error' for problems that are always wrong and uses 'warning' for numbers that are merely worth a second look.
Can a two-digit year cause this kind of error?
Yes. If a birth year was entered or OCR'd as '1898' but a later edit trimmed it to '98' without the century, and it gets interpreted as 1998, every downstream date comparison involving that person breaks — a marriage in 1920 now appears to happen 78 years before the person was born.
Does GEDCOM have a way to mark an uncertain date instead of just guessing?
Yes — GEDCOM's date qualifiers (ABT, EST, BEF, AFT, BET/AND) exist precisely so you can record 'around 1850' or 'before 1900' instead of inventing a false-precision exact date. See the linked guide for the full syntax.