GEDCOM Dates Explained: Calendars, Ranges and Impossible Birthdays

Dates are the spine of a family tree. They order lives, prove identities, and separate the John Smith you want from the four you do not. They are also the field where GEDCOM files fail most. Not because the rules are hard — the core form takes one line to state — but because real research is full of dates that are rough, ranged, doubted, and drawn from calendars most of us never use.

This guide explains the GEDCOM date grammar: the exact forms a date may take, how ranges and estimates are written, how other calendars are marked, and how validators catch the birthdays that cannot be true. For the wider map of file faults, see why GEDCOM exports fail validation. To check the dates in your own file, the validation report from the GedConvert tool on the home page lists each bad date with its line number.

The Core Form

A full GEDCOM date is three parts, in this order: day number, month code, year number. Spaces between them. Like this: 12 MAR 1904.

The month is a three-letter code, always in English, no matter what language the rest of the file uses:

Parts may be dropped from the left when they are unknown. A date may be MAR 1904, or just 1904. What may not change is the order and the codes. 1904-03-12 is not a GEDCOM date. March 12, 1904 is not a GEDCOM date. 12/3/1904 is not a GEDCOM date, and it is also a trap: half the world reads it as 12 March and the other half as 3 December. The grammar exists to kill that guesswork. A file that follows it can be read by any program in any country and mean the same day.

Under GEDCOM 7.0, a date may also carry a time in strict cases, written after the date in a fixed form. Everyday family history rarely needs it. Birth and death dates at day precision cover nearly all research. If you see a time in a file, it is legal in 7.0 and should be treated as part of the date value, not as a note.

Dates That Are Not Single Days

Most real research dates are not single days. The grammar has honest forms for each kind of not-quite-known, and using the right one matters. A program can sort, search, and check these forms because each says exactly what is known and what is not.

ABT — about. ABT 1850. The date is an estimate. Use it when you have derived a year from other facts: an age on a census, a child's birth, a marriage bond. ABT tells the next reader: this is reasoned, not recorded.

EST — estimated. In the spec's terms, EST is an estimate based on a stated rule or calculation, where ABT is a looser judgment. Many programs use the two as one. If your program offers both, EST suits a date computed from a formula; ABT suits a date judged from the whole picture.

CAL — calculated. CAL 1850. The date was worked out from another value, classically an age at death read from a stone or a record. "Died 1901, aged 51" yields CAL 1850 for the birth — or 1849, since the birthday may not have fallen yet that year. CAL marks the math so no one mistakes it for a record.

BEF and AFT — before and after. BEF 1900. AFT 12 JUN 1880. Bounds, not guesses. A will proved in 1900 gives BEF for the death. A man who signs a deed in 1880 gives AFT for nothing about his death but a firm fact: he was alive on that date, so his death is AFT that date.

BET … AND … — between. BET 1880 AND 1890. The event fell in a range with both ends known. Census gaps are the classic case: present in 1880, gone in 1890, died between.

FROM … TO … — a period. FROM 1910 TO 1915. This form is for things that span time, like a residence or a job, where BET would claim one unknown day. Periods describe spans; ranges describe an unknown point inside known bounds. The spec keeps them apart, and so should you.

INT — interpreted. INT 1904 (Easter 1904). The date was read from words that are not a date in the grammar — a feast day, a regnal year, "the spring after the flood." INT holds your reading first and the original words in brackets after it. The original words are never thrown away.

The Phrase Rule: Keep Poetry Out of the Date Field

Any words that are not one of the forms above do not belong in a DATE value — with one clean escape. GEDCOM allows a date phrase: free text placed in brackets, like (sometime in spring 1904), stored in a special way the spec defines so programs know it is text, not a parsed date. The honest workflow is: parsed form in the date field where you can give one, original words in a note, and a bracketed phrase only when no parsed form is defensible.

Files fail validation by the hundred when programs write raw text into the date field: "March 1904?", "abt. 1850s", "1904 or 1905", "unknown." Each one breaks the grammar. Worse, each one breaks the next program's sort and search. A tree sorted by a text date field is sorted by the alphabet, which puts "1904 or 1905" wherever the letter sorting falls. The fix preserves the meaning and repairs the form: ABT 1904 in the field, the question mark's doubt in the note.

Calendars: When the Year Is Not the Year

The default calendar in GEDCOM is the Gregorian — the calendar most of the world uses now. History was not so tidy. The spec lets a date state its calendar with an escape code placed before the date:

The Julian case catches the most researchers. Britain and its colonies switched calendars in 1752: Wednesday 2 September was followed by Thursday 14 September, and the start of the year moved from 25 March to 1 January. Dates in the old style, above all January-to-March dates in years before 1752, are often written double, like 10 FEB 1731/32 — old style year 1731, new style 1732. In GEDCOM, the Julian escape marks the calendar, and many programs accept the double-year form in the year part. What you must not do is silently convert. Record the date as the source gives it, mark the calendar, and let a note explain. The researcher who converts without a trace steals the next reader's chance to check the math.

GEDCOM 7.0 kept the same calendar system and clarified the rules for month names in the Hebrew and French Republican calendars, whose months are not JAN to DEC. A Hebrew date uses its own month codes, such as TSH for Tishrei. Those codes are part of the grammar, and a validator checks them only when the calendar escape says to.

Impossible Birthdays: Dates That Parse and Still Cannot Be True

A date can pass the grammar and fail the world. Validators run a second class of checks — not "is this written right" but "can this be true with the other dates around it?" The classic catches:

Treat each flag as a question, not a verdict. There are edge truths: a child can be born months after a father's death, just not years. A mother of 15 was rare, not unknown, in some times and places; a mother of 6 is an error somewhere. Twins, adoptions, and step-ties confuse simple checks when links are loose. The validator's job is to point. Your job, with the sources in hand, is to judge. More on how these warnings sit in the full report is in the validation guide linked at the top.

Above all, do not fix an impossible date inside the file by guessing. If the stone says a man died in 1890 and the census shows him alive in 1900, the answer lies in research — is it the same man? — not in picking the date you like better. Fix facts in your research program, with the sources open, and let the next export carry the repair. Machines fix grammar. People fix truth.

Writing Dates That Age Well

A few habits make every future export cleaner. Enter dates from sources as recorded, with BEF, AFT, BET, and ABT doing the honest work instead of typed question marks. Put the reasoning for an estimated date in a note while you still remember it: "Age 30 in the 1880 census" is a gift to your future self. Keep calendar escapes on pre-1752 British dates and any non-Gregorian source. And run a date check after any merge, since merges are where impossible birthdays breed. The tool on the home page lists date faults on the free validation report; paid plans add the repaired file, which fixes grammar-level faults and leaves fact calls to you. The split is set out on the pricing page.

Frequently Asked Questions

Why does my program show a date one way and the file store it another? Programs display dates in your local style — 12/3/1904 or March 12, 1904 — but store them in the file in grammar form: 12 MAR 1904. The display is for you. The grammar is for every other program.

Is a year by itself a legal GEDCOM date? Yes. 1904 alone is a full, legal date value. So is MAR 1904. Missing parts mean "not known," and programs handle them cleanly.

What do I do with "died young" or "died in infancy" in an old note? Keep the words in a note. If the death plainly falls between the birth and a bound — a sibling's birth, a census where the child is absent — a BET range may be honest. If you know nothing but the words, the note alone is the honest record.

Can GEDCOM hold a date with a question mark, like 1850? Not in the parsed field. The doubt belongs in the form — ABT 1850 — or in a note that says what is doubted. A literal question mark in the DATE value breaks the grammar.

Why did a validator flag a birth in 1731 when my program says 1732? Almost always a calendar issue: an old style date around the 1752 change, or double dating. Check whether the source used the Julian calendar and whether the year was written 1731/32. Mark the calendar rather than changing the year.

Do ranges import well into other programs? Yes, when they use the grammar's own words — BET, BEF, AFT, ABT. Programs parse those forms into their own range handling. Ranges typed as free text are the ones that break.

References

• https://gedcom.io/ — The home of the GEDCOM standard, whose specs define the date grammar, calendar escapes, and date phrases.
• https://www.archives.gov/research/genealogy — The U.S. National Archives guide to genealogy research and records.
• https://www.loc.gov/ — The Library of Congress, a major source of census, local history, and family history material.