How GEDCOM Dates Work: ABT, BEF, AFT, and Other Qualifiers Explained

Genealogical dates are rarely as certain as a birth certificate — sometimes they're approximate, sometimes calculated from other facts, sometimes only known within a range. GEDCOM handles this with a fixed set of qualifiers rather than forcing every date into a false precision it doesn't actually have.

Single approximate dates

ABT (about) — the date is approximately known, e.g. ABT 1850. This is the most common qualifier for a date pulled from an imprecise source, like a census record that only states an age.

CAL (calculated) — the date was worked out mathematically from other known information, e.g. an age at a known event, rather than stated directly in any source.

EST (estimated) — similar to CAL, but used when the date is a broader inference rather than a direct calculation — for instance, estimating a birth year from a marriage record decades later, using typical age patterns rather than an exact formula.

Bounded dates

BEF (before) — the event happened at some point before the stated date, e.g. BEF 1900, used when a source proves an upper bound but not an exact date.

AFT (after) — the reverse: the event happened after the stated date, e.g. AFT 1875.

BET ... AND ... (between) — the event happened within a stated range, e.g. BET 1900 AND 1905. This differs from a period (below) in that it describes uncertainty about a single point-in-time event, not a duration.

Periods and ranges

FROM ... TO ... — used for events that genuinely span a duration, like a period of residence or employment, rather than uncertainty about a single date, e.g. FROM 1920 TO 1935.

INT (interpreted) — a date that was interpreted from other text and requires an accompanying explanatory phrase, used when a source states a date in a non-standard way that needed manual interpretation to convert into GEDCOM's date format.

No qualifier at all

A plain date with no prefix, such as 4 JUL 1826, asserts the date as exactly known — this is the default and most common form when a source states a date directly and unambiguously.

Dual dating and the calendar switch

Different countries switched from the Julian to the Gregorian calendar at different points between the 16th and 20th centuries, which creates a real ambiguity for dates recorded during that transition — the same day could be described differently depending on which calendar the original record used. GEDCOM supports representing this explicitly, though how consistently a given program displays or preserves dual-dated events varies, which is part of the broader compatibility gap covered in GEDCOM 5.5.1 vs. 7.0: What Actually Changed — 7.0 tightened the date grammar specifically to make ranges and calendar-spanning dates parse consistently across software, where 5.5.1 left more room for programs to interpret them differently.

Why this matters beyond curiosity

These qualifiers are exactly the kind of value a parser checks when validating a DATE line — a date string that doesn't match any of these patterns, or a qualifier applied inconsistently, is a common source of the malformed-record errors covered in Common GEDCOM Upload Error Messages, Explained. Knowing the actual vocabulary makes it possible to tell, at a glance, whether a date in your file is asserted as fact or genuinely uncertain — information that's easy to lose entirely if a program collapses every qualifier down to a single displayed date.