Dates & places

Almost every fact in a tree happens somewhere and somewhen, so DATE and PLAC are the two tags you’ll write most. GEDCOM dates are a small, precise language — exact, approximate, ranged, non-Gregorian, or “I can only describe it in words” — and places are jurisdictions with optional coordinates. These recipes cover the lot, version by version.

New to reading GEDCOM lines? Skim How GEDCOM works first — every recipe shows the underlying lines, but the app’s date editor builds them for you from a form.

Write an exact date

The structure. A date sits on a DATE line, usually beneath an event. The plain form is day, month, year, with the month as a three-letter uppercase abbreviation:

1 BIRT
2 DATE 12 MAR 1832

The month is JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC — letters, never digits. 12 MAR 1832 is unambiguous in any country; 12/03/1832 is not, which is why GEDCOM spells the month out.

In the app. Add a DATE line beneath an event and open the Edit date dialog from the value; autocomplete offers DATE in the right places, and the date editor gives you Day, Month, and Year fields with the qualifier left on Exact. Type into the fields and it writes the line for you. You can always switch the qualifier or Edit as text for anything the form doesn’t cover.

Across versions. The exact day-month-year form is identical in 5.5, 5.5.1, and 7.0. The only fine print: GEDCOM 7.0 requires every date to carry a year — a day and month with no year isn’t a date there, it’s a phrase (see Record an uncertain date in words).

Validation notes. The checker flags a DATE whose value isn’t a recognisable date — a numeric month (12 03 1832), a missing year in 7.0, or an out-of-range day. A bare day-and-month with no year (12 MAR) is treated as a date phrase, not an exact date, in every version.

See also: The date editor · Write approximate dates.

Write approximate dates (about, estimated, calculated)

The structure. When a date isn’t exact, prefix it with a qualifier keyword. Three say roughly:

2 DATE ABT 1850
2 DATE EST 1850
2 DATE CAL 12 MAR 1832

• ABT — about: the date is near this, but not exact.
• EST — estimated: inferred from some other event (e.g. an age at a census).
• CAL — calculated: worked out mathematically from other data (e.g. a birth date from a death date and an age).

The keyword takes the same date that follows — a year alone, a month and year, or a full date.

In the app. In the date editor, pick the Type — About, Estimated, or Calculated — and fill in the date fields. The app writes ABT, EST, or CAL for you.

Across versions. All three keywords — ABT, EST, CAL — exist and mean the same thing in 5.5, 5.5.1, and 7.0. This recipe converts cleanly in every direction.

Validation notes. The keyword must be one of the recognised three; a typo like ABOUT 1850 is flagged as an unparseable date. A useful spec habit: the standard prefers writing imprecision as a coarser date (MAY 1890) over ABT 12 MAY 1890, because no program defines exactly how loose ABT is — see Write partial dates.

See also: Write date ranges and periods.

Write date ranges and periods (before/after/between, from/to)

Goal. Express that an event happened somewhere within a span (a range) or that a state lasted across a span (a period). GEDCOM keeps these two ideas distinct.

The structure. A range estimates a single event fell somewhere in an interval:

2 DATE BEF 1850
2 DATE AFT 1850
2 DATE BET 1850 AND 1855

A period describes something that lasted from one date to another — a residence, an occupation:

1 RESI
2 DATE FROM 1904 TO 1915
2 DATE FROM 1904
2 DATE TO 1915

• BEF / AFT — before / after a date.
• BET … AND … — between two dates (inclusive).
• FROM … TO … — a span; either end may stand alone (FROM 1904, TO 1915).

The difference matters: BET 1850 AND 1855 says one event happened once in that window; FROM 1850 TO 1855 says a state persisted the whole time.

In the app. Choose the Type in the date editor — Before, After, Between, From, To, or From and to — and the editor shows From date / To date fields as the form needs them, then writes the BEF / AFT / BET…AND / FROM…TO line.

Across versions. The range keywords (BEF, AFT, BET … AND …) and the period keywords (FROM, TO, FROM … TO …) are identical across 5.5, 5.5.1, and 7.0. The only nuance is in 7.0, where a DATE carrying a period value (and a DatePeriod-typed field generally) may be the empty string when only a substructure like a phrase or time is meaningful — a corner you’ll rarely meet.

Validation notes. BET requires its AND; BET 1850 with no second date is flagged. Range keywords belong on event dates; using a period (FROM…TO) for a one-moment event, or a range for a spanning attribute, is grammatically valid but semantically off — the checker won’t stop you (the app is permissive, not gated), it’s a judgement call.

See also: Write approximate dates · Record an uncertain date in words.

Write partial dates (year-only, month + year)

The structure. You don’t need a full date. Drop the day, or the day and month, and write only what you know:

2 DATE 1850
2 DATE MAR 1850

A year alone, or a month and year, is a complete and valid date value — not an error. The spec even prefers a coarse MAR 1850 over a falsely precise ABT 15 MAR 1850 when you only know the month.

In the app. Leave the Day field (or the Day and Month fields) empty in the date editor; it writes the partial date with the qualifier still set to Exact. The Month picker has a blank entry (—) for “month unknown”.

Across versions. Year-only and month-plus-year forms are valid in all versions, written the same way. One hard rule splits 7.0 from the rest: 7.0 requires a year. You can omit the day and the month, but never the year — MAR alone or 15 MAR is a phrase in 7.0, not a partial date. In 5.5 / 5.5.1 a bare month-and-day is also treated as a phrase rather than a date.

Validation notes. A partial date is fine; a date missing its year is flagged in 7.0. When the year itself is unknown, don’t force a fake one — record it as a phrase (next recipes) instead.

See also: Write an exact date · Record an uncertain date in words.

Use a non-Gregorian calendar

Goal. Record a date as it was originally given — in the Julian, Hebrew, or French Republican calendar — rather than silently converting it to Gregorian.

The structure (5.5 / 5.5.1). The calendar is named by an escape wrapped in @#D…@, placed immediately before the date:

2 DATE @#DJULIAN@ 14 FEB 1721
2 DATE @#DHEBREW@ 1 TSH 5780
2 DATE @#DFRENCH R@ 18 BRUM 8

The escapes are @#DGREGORIAN@ (the default, so usually omitted), @#DJULIAN@, @#DHEBREW@, and @#DFRENCH R@ — note the space before the R. Each calendar has its own month abbreviations (Hebrew TSH, CSH, …; French Republican VEND, BRUM, …).

The structure (7.0). Version 7.0 drops the @#D…@ escape syntax. The calendar is a bare tag at the front of the value:

2 DATE JULIAN 14 FEB 1721
2 DATE HEBREW 1 TSH 5780
2 DATE FRENCH_R 18 BRUM 8

The four defined calendar tags are GREGORIAN (the implied default), JULIAN, HEBREW, and FRENCH_R — note the underscore, and that an absent calendar means Gregorian. 7.0 also adds a trailing epoch marker, BCE, for dates before the common era.

In the app. Open the date editor and pick the Calendar — Gregorian, Julian, Hebrew, or French Republican. The month picker switches to that calendar’s months (Tishrei, Cheshvan, … for Hebrew; Vendémiaire, Brumaire, … for French Republican), and the app emits the correct escape or bare-tag form for your file’s version.

Across versions.

• 5.5 and 5.5.1 use the @#DJULIAN@ / @#DHEBREW@ / @#DFRENCH R@ escape form (with @#DGREGORIAN@, @#DROMAN@, @#DUNKNOWN@ also reserved). Roman and Unknown were never given a defined meaning.
• 7.0 uses the bare tags JULIAN / HEBREW / FRENCH_R and the implicit GREGORIAN, plus the BCE epoch. Converting 5.5.x ↔ 7.0 rewrites the escape to the tag (or back) — @#DFRENCH R@ ⇄ FRENCH_R — best-effort; a Roman or Unknown escape from a 5.5.x file has no 7.0 equivalent and is carried as best it can.

Validation notes. The calendar name must match the date’s months — Hebrew months under a JULIAN date, or a Gregorian month under HEBREW, are flagged. In 7.0, FRENCH_R is spelled with the underscore (not FRENCH R), and the escape syntax @#D…@ is not valid — it belongs to 5.5.x only.

See also: The date editor · The spec viewer (look up a calendar’s month tags).

Record an uncertain date in words (a date phrase)

Goal. Capture a date you can only describe — “the spring after the war”, “Whitsun 1880” — when no keyword or partial date fits.

The structure (5.5 / 5.5.1). The phrase goes in parentheses, as the whole date value or after an INT (interpreted) keyword that pairs it with your best-guess date:

2 DATE (the spring after the war)
2 DATE INT 1865 (the spring after the war)

INT <date> (<phrase>) says “I read it as 1865, from this wording”; the bare (<phrase>) form gives only the words.

The structure (7.0). Version 7.0 moved the phrase into a PHRASE substructure beneath the date, so the DATE value stays a clean (possibly empty) date and the words live one level down:

2 DATE 1865
3 PHRASE the spring after the war

If you have only the words and no usable date, the DATE value may be left empty with the PHRASE beneath it:

2 DATE
3 PHRASE the spring after the war

In the app. In the date editor, choose Interpreted (to pair a date with words) or Phrase (words only); fill the Text field. The app writes the version-correct form — an INT … (…) value in a 5.5.x file, a PHRASE substructure in a 7.0 file.

Across versions.

• 5.5 and 5.5.1 put the phrase inline in the date value: INT <date> (<phrase>) or (<phrase>).
• 7.0 uses the PHRASE substructure and removed the inline-parenthesis form. Converting a 5.5.x INT 1865 (…) to 7.0 splits it into DATE 1865 + 3 PHRASE …; converting 7.0 → 5.5.x folds the PHRASE back into the parenthesised value — best-effort, and faithful for the common cases.

Validation notes. In 5.5.x, the phrase must be wrapped in matching parentheses; an unbalanced paren is flagged. In 7.0, free-text words placed directly in the DATE value (instead of in PHRASE) are flagged — the value must be a date or empty. One 7.0 limitation worth knowing: a PHRASE can’t itself carry a language tag, so non-default-language wording needs a workaround (an extension tag or a source text) — a rare corner.

See also: Write partial dates · Notes (for longer commentary on a date).

Record a place and its jurisdictions

The structure. A place is a PLAC line whose value is a comma-separated list of jurisdictions, smallest first:

1 BIRT
2 DATE 12 MAR 1832
2 PLAC Boston, Suffolk, Massachusetts, USA

Read left to right: town, county, state, country. An empty element is still held by its comma — a place known only down to the county is , Oneida, Idaho, USA. The optional FORM line spells out what each position means:

2 PLAC Boston, Suffolk, Massachusetts, USA
3 FORM City, County, State, Country

You can set a default FORM once in the file header so you don’t repeat it on every place — the app manages that for you.

In the app. Type the PLAC line beneath an event; autocomplete offers PLAC where it’s valid and FORM beneath it. The inspector shows the place under its event (Inspector). Keep the comma positions consistent across records so the smallest-to-largest order holds.

Across versions. The PLAC value, the smallest-to-largest comma convention, and the FORM sub-line work the same in 5.5, 5.5.1, and 7.0. What grows around the place across versions — coordinates, name translations — is covered in the next two recipes.

Validation notes. PLAC appears at most once per event, and FORM at most once under it. There’s no enforced jurisdiction count — a place with fewer elements than its FORM declares is allowed (blanks are assumed). The checker won’t reorder your jurisdictions; getting them smallest-first is on you.

See also: Add coordinates to a place · Record place name form and translations.

Add coordinates to a place

The structure. Latitude and longitude hang off a MAP block beneath PLAC. Each coordinate is a hemisphere letter (N/S, E/W) followed by decimal degrees:

2 PLAC Boston, Suffolk, Massachusetts, USA
3 MAP
4 LATI N42.358056
4 LONG W71.063611

Minutes and seconds are not used — convert them to a fraction of a degree first (9′ 3.4″ becomes .150944). LATI is N/S (0–90); LONG is E/W (0–180). The sign is the letter, never a leading -.

In the app. Add the MAP line beneath PLAC, then LATI and LONG beneath it — autocomplete offers each in turn. Enter the values in the N…/W… form shown above.

Across versions. This is a sharp version line:

• 5.5 has no coordinates at all. Its place structure is just PLAC + FORM (+ notes/sources) — no MAP, LATI, or LONG. Record coordinates in a note or a custom tag if you must keep them in a 5.5 file.
• 5.5.1 added the MAP block with LATI and LONG (the same N…/E… letter-prefixed form).
• 7.0 keeps MAP / LATI / LONG identically — same letters, same fractional degrees.

So converting a place up from 5.5 gains nothing automatically (there were no coordinates to carry); converting a coordinate-bearing 5.5.1 or 7.0 file down to 5.5 drops the whole MAP block — best-effort, with a warning, because 5.5 has nowhere to put it.

Validation notes. LATI must start with N or S, LONG with E or W; a bare -42.36 or a latitude over 90 is flagged. MAP, LATI, and LONG in a 5.5 file are flagged as not valid there. Under MAP, both LATI and LONG are required — a MAP with only one coordinate is incomplete.

See also: Record a place and its jurisdictions · The spec viewer (look up the place structure for your version).

Record place name form and translations

Goal. Say what the jurisdiction positions mean (FORM), and — in 7.0 — record the same place name in another language or script (TRAN).

The structure (FORM, all versions). FORM labels the comma positions of the PLAC value:

2 PLAC München, Bayern, Deutschland
3 FORM City, State, Country

The structure (7.0 translations). Version 7.0 adds a LANG for the place’s own language and TRAN lines for translated/transliterated forms, each TRAN carrying a required LANG:

2 PLAC München, Bayern, Deutschland
3 FORM City, State, Country
3 LANG de
3 TRAN Munich, Bavaria, Germany
4 LANG en

The structure (5.5.1 phonetic/romanized). 5.5.1 has no TRAN/LANG under a place, but it does offer FONE (phonetic) and ROMN (romanized) variants of the place name, each with a required TYPE:

2 PLAC 東京, 日本
3 ROMN Tōkyō, Nihon
4 TYPE romaji

In the app. Autocomplete is version-aware: it offers FORM everywhere, FONE/ROMN (with TYPE) in a 5.5.1 file, and LANG/TRAN (with TRAN’s own LANG) in a 7.0 file — so you’re always shown the right tags for the place.

Across versions.

• FORM under PLAC exists in all versions and is written identically.
• LANG and TRAN (translated place names) are a 7.0 addition; each TRAN requires its LANG.
• FONE and ROMN (phonetic and romanized place names) are a 5.5.1 addition; 5.5 has neither. Converting 5.5.1 FONE/ROMN ↔ 7.0 TRAN maps as faithfully as it can — best-effort, since the mechanisms differ. Converting either down to 5.5 drops the variant — best-effort, with a warning.

Validation notes. Each 5.5.1 FONE/ROMN requires its TYPE; each 7.0 TRAN requires its LANG. A TRAN under a place in a 5.5.1 file, or a FONE/ROMN in a 7.0 file, is flagged as the wrong version’s tag. A FORM whose element count doesn’t match the PLAC value is allowed — missing positions are assumed blank.

See also: Record phonetic and romanized name variants (the same idea for personal names) · How GEDCOM works (non-Latin text needs a UTF-8 file).

---

Next: wiring people into families → Relationships.