Why "About 1850" Breaks Most Genealogy Software

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.

Uncertainty isn’t an edge case. It’s most of the evidence.

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.

The storage problem is mostly solved. Everything downstream isn’t.

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:

• Search. You search for someone born in 1850. A record that says “between 1845 and 1855” doesn’t come back, because the search compared two values for equality and they weren’t equal. The record you needed was right there and the software said no results.
• Sorting and timelines. “Circa 1850” gets sorted as though it were 1 January 1850, which puts events in a confident order that the evidence doesn’t support.
• Merging duplicates. Two records for the same man, one saying “abt 1837” and one saying “1836.” A merge that picks a winner throws away the fact that these two estimates agree with each other — which was the most interesting thing about them.
• Round-tripping. Export, import somewhere else, and the modifier is the first thing to get flattened, for the same reason citations do (see the GEDCOM import post). You end up with a bare year and no memory that it was ever a guess.

The date field isn’t lying to you. It’s the search box that is.

What to do about it, whatever you’re using

This is fixable in your own practice today, in any software:

1. Never type a precise date you can’t source. If the evidence is an age on a census, the date is approximate — record it that way, even if it feels less tidy.
2. Use the modifiers your software does support. If it takes “abt 1850” or “bef 1900”, use them. Displayed-only is still better than a fabricated exact date, because at least the next person sees the data.
3. Record the original wording somewhere it will survive. “Aged 43 at the 1880 census, Cook County” is worth more than any date you derive from it, because the next researcher can re-derive it differently and see why.
4. When you search, search wide on purpose. Assume the tool is doing an equality match and compensate — search a range or a nearby year before concluding a record doesn’t exist. A lot of “I can’t find him” is really “the query was more confident than the data.”

What GTF actually does, specifically

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.

Where we’re not done

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.