You have a census page. It says your ancestor was 43 years old in 1880. That’s not a birth date — it’s a clue that points at 1836 or 1837, assuming the person answering the door knew his age, and assuming the enumerator wrote down what he heard. You open your software, click into the birth date field, and it wants something like 12 Mar 1837.
So you type 1837. Maybe you put a note somewhere explaining that it’s an estimate. Then you export a GEDCOM, someone imports it, and three years later a stranger’s tree says your ancestor was born in 1837 — no note, no census page, no hedge. A guess grew up into a fact while nobody was watching.
That’s the actual cost of fabricated precision, and it’s why this is worth caring about more than it sounds.
Here’s the thing that trips up software design in this field: in genealogy, the imprecise date is not the exception you handle after you’ve built the normal case. It is the normal case.
Ages on censuses are approximations. Tombstones round. Church registers record the baptism, not the birth. Death certificates are filled out by a grieving relative guessing at their mother-in-law’s birth year. What you can actually prove is usually a shape — “sometime in the 1840s,” “before the 1871 probate, because she’s referred to as deceased,” “after the 1863 marriage, since he’s listed as a widower by then.”
Every one of those is a real, defensible research conclusion. And every one of them fits badly in a box that wants a day, a month, and a year.
To be fair to the software: this is not a case where nobody thought about it. GEDCOM has supported date modifiers for decades — ABT for about, BEF for before, AFT for after, BET ... AND for a range, EST for estimated. Most serious desktop programs will let you type “abt 1850” and will keep it.
So if the spec handles it and the tools store it, why does it still feel broken?
Because storing a value and understanding it are different things. The qualifier tends to survive as decoration — something displayed back to you — while every feature that actually does work with dates quietly treats the date as a point. Specifically:
The date field isn’t lying to you. It’s the search box that is.
This is fixable in your own practice today, in any software:
Every date is stored as a range, including exact ones. If you enter a firm date, it’s kept as a range whose start and end are that same day — there’s no separate “real dates” path and “fuzzy dates” path that behave differently, because that split is exactly where other tools lose the plot.
Typed text is parsed into that structure. “circa 1945,” “about 1900,” “around 1850,” “abt 1775,” “ca. 1920,” “before 1900,” “bef 1880,” “prior to 1850,” “after 1850,” “1840-1850,” “between 1840 and 1850,” and decade forms like “early 1900s” or “mid 1850s” all resolve to a start and an end, with a type of circa, before, after, or range. The GEDCOM abbreviations are understood in their punctuated and unpunctuated forms — ABT, abt., even the terse AB some exports emit — along with EST, CAL, and INT, and a modifier composes with whatever precision follows it: “circa 1850” gets a ±5-year window, ABT APR 1684 a ±1-month one, “about 1 Jan 1635” ±15 days. The window scales with how much you actually said.
The older and stranger notations work too, because this hobby is made of them. Double-dated Old Style/New Style dates like 1 Feb 1723/24 — constant in pre-1752 English and colonial records, mangled almost everywhere else. Quaker numbered months: 15 first month 1723 resolves correctly, including the pre-1752 month shift. Regnal years like 3 George III. And the GEDCOM calendar escapes for Julian, Hebrew, and French Republican dates, so @#DHEBREW@ 15 NISAN 5765 means what it says.
When text genuinely can’t be parsed — “1718 or 1725,” a typo, a transcriber’s note — it is not silently coerced into a guess and not rejected either. Your text is stored verbatim, the date is marked unknown, and the record is flagged for your review, because an event that looks dated but can’t be searched by date is exactly the kind of quiet failure this post is complaining about.
The original text you typed is preserved alongside the parsed range, and for imprecise dates it’s what gets displayed back to you. The software’s interpretation never overwrites your wording.
And search matches on overlap rather than equality. A search for a range returns any record whose range intersects it — so “born around 1850” finds the person recorded as “between 1845 and 1855,” and vice versa. That’s the part that actually changes your day, because it’s the difference between finding the record and concluding it isn’t there.
Two honest gaps. Neither affects whether a record is found — both are about what happens afterwards.
Right now a vague match and a precise one come back weighted the same. If you search for 1850, a record that says exactly 1850 and a record that says “circa 1852” — inside its ±5-year window — are both hits, and nothing pushes the exact one higher. That’s a ranking problem, not a correctness problem, but it’s real and it’s on the list.
The circa window also can’t be tuned. It scales with precision, as described above — but that’s precision, not confidence. A “circa” derived from an age on a census deserves a tighter window than one derived from a family story, and both are year-precision, so there’s currently no way to say so.
Neither of these is a reason to fabricate a date. But you should know where the tool is soft before you trust it, which is the same argument I made about AI transcription — I’d rather you have an accurate picture of the edges than an impressive one.
If you’ve got a date case that breaks this — a calendar, a notation, a record type that doesn’t fit a range — I’d genuinely like to see it. The free tier has no time limit if you want to throw an awkward one at it.