Help:Date Conventions


Page Status

This page is a preliminary draft, a straw man if you will, to help in developing conventions about date usage. Discussion of suggestions and changes should be done on the associated talk page.

I made some modifications trying to remove gratuitous differences between the proposal and the GEDCOM specification. A kindly suggestion aggravated a nagging suspicion that this was a good thing to do. --Jrich 14:43, 22 February 2009 (EST)

General Formatting Rules for Dates

  • The preferred format of dates is D MMM YYYY. For example, 4 Sep 1753.

Dates should never be given in numeric form, as there is far too much ambiguity inherent in these forms. If the record of the event uses numeric dates, it should be converted and entered in the form above. (See the discussion of conversion in #Sources, below).

The source for all dates should be cited, so its credibility may be assessed by the WeRelate community (See #Sources).

Leading Zeroes

The WeRelate stylistic preference concerning leading zeroes is a subset of the GEDCOM specification. The day of the month should be expressed as 1 or 2 digits with no leading zero. Years 1000 or later should always be expressed with 4 digits ("1753"). Years before 1000 should be expressed with four digits including leading zeroes ("0953"), keeping in mind that events before 0700 are out of scope for WeRelate.

Month Abbreviations

Please use the three-character month abbreviations from the following set: "Jan", "Feb", "Mar", "Apr", "May", Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec". Please use either title case ("Jan"), all upper case ("JAN"), or all lower case ("jan").


Dates should be made as precise as is known. Often a date is not known precisely, in which case, the appropriate qualifier should be used to indicate what is known, and with what preciseness, as an aid to subsequent researchers. Often, the use of any qualifier may require a note to explain how it was arrived at, unless the imprecise date was taken literally from the cited source. To paraphrase the GEDCOM specification, an imprecise date should not be made to look like it is precise.

GEDCOM does not mandate the case of data, so qualifiers may be all upper case, all lower case, or title case. Periods should not be used.


  • The qualifier "BEF" may be used to indicate that an event occurred by the indicated date (inclusive). For example, a will dated 15 Jun 1863 may refer to a deceased neighbor, so the death date of the neighbor would be specified as Bef 15 Jun 1863.


  • The qualifier "AFT" may be used to indicate that an event occurred after the indicated date (inclusive). For example, if a person acknowledged a deed on 22 Apr 1704, their death date would be Aft 22 Apr 1704.


  • The qualifier "BET ... AND" may be used to indicate a range of dates, where known dates define a window within which the event occurred. For example, if a person's will was dated 10 Nov 1798, and proven 20 Nov 1798, the death date would be specified Bet 10 Nov 1798 And 20 Nov 1798.
Note: in the example given, the death date should not be abbreviated "Nov 1798", or "1798", since both these forms represent a loss of precision. An incomplete date is simply shorthand for a range of dates including a whole month, or a whole year, and should not be used unless this is exactly the range of dates desired. A vital record that says "John, s. John Doe and Jane his wife, born ---, 1692" would be input as 1692. However, a person whose will is dated 8 Aug 1652, but whom the town records says died "Aug 1652", should show the more precise death date of Bet 8 Aug 1652 And 31 Aug 1652, rather than simply using the incomplete date specified in the town records.


  • When a date may be calculated, the qualifier "CAL" should be applied. If somebody dies 2 Jun 1905, aged 83, then their birth date would be calculated to be Cal 1822.
Technically, the previous example could be Bet 2 Jun 1821 And 2 Jun 1822, but since statements of age are not terribly reliable, the last-mentioned form probably overstates the precision. Sometimes time spans may be given using months as well as years, which allows calculation to a greater precision, so a calculated date may include a month, and even day, when appropriate, as in Cal May 1822.
This qualifier should only be used when there is a known date, and a known time span, to use in calculating a date, and not when the date is estimated based only on a known date. For example, since people get married at different ages, any birth date derived from the marriage date must be estimated, not calculated.


The qualifier "EST" may be used when a date has been guessed using known facts. It is often useful to at least approximate a date in order to distinguish between others of the same name, or to establish a timeline in order to do feasibility assessments. It is typical for estimates to contain only a year, as estimates are understood to potentially be off by a few years.
  • For example, if a person is married in 1805 and soon has children, you may want to list their birth as Est 1780.
Since there is also an underlying assumption embedded in an estimate, all estimates should have a note explaining how it was arrived at, in this case by assuming 25 is a typical age for marrying and starting a family.
  • When it makes sense, convert the EST qualifier to the more precise BEF, AFT, or BET ... AND qualifiers.
BEF, AFT, and BET ... AND are usually more precise in terms of expressing exactly how the date is constrained, than the EST qualifier. If a colonial man bought property 17 Jul 1687, it would be best to express the birth date as Bef 1666, rather than Est 1666. A cited source would identify the deed, and an explanation would note the assumption that they were at least legal age, 21 for men, when they purchased the land.


The GEDCOM specification defines "ABT" to be an inexact date. In practice, "ABT" has probably been used indiscriminately for all imprecise dates. Hence, it has developed some ambiguity as to the reliability of the date it qualifies, ranging from wild guesses to fairly solid calculated dates. To communicate as precisely as possible, the qualifiers EST and CAL should be used in preference to ABT whenever they apply. If ABT is used, it will be generally understood to be similar in meaning to EST, and it requires clear source citations that indicate how precise and reliable the estimated date is.
  • Because of its widespread use, ABT is acceptable, but EST and CAL are preferred if they apply.
Occasionally, a source is imprecise, and ABT is the only way to express this. For example, in colonial times, when families would move to a new town, the father would often provide birth dates for his children to the town clerk, even though they were born before the move. If the father's memory was faulty, these records sometimes read "born about the 15 of June 1684" or similar.
  • As with EST, many prospective uses of ABT would be better framed using BEF, AFT, or BET.
A vital record says "Sarah, b. end of September, 1645" would best be input as Bef 30 Sep 1645 since the meaning of "end" is ambiguous. Abt 30 Sep 1645 might imply dates in early October are valid, when they are not. Bet 15 Sep 1645 And 30 Sep 1645 would also be appropriate.

Other GEDCOM Qualifiers

The FROM ... TO qualifier is used to indicate an interval (inclusive) over which something was always true, which is slightly different than identifying an interval within which a discrete event happened (i.e., BET ... AND). Thus, FROM ... TO may be useful with some of the auxiliary fact types such as residence and occupation, as opposed to the main genealogy events of birth, marriage and death, which tend to be discrete events.
The INT qualifier of GEDCOM ("interpreted from knowledge about the associated date phrase included in parentheses) is not to be used, since interpretations should be explained as part of the source citation or in a note.

Accuracy in Applying Dates

The date field for birth, death and other events should be the dates that the specified event took place. Do not put the dates of proxy events in the place of the actual event. Instead, enter proxy dates as their own fact.

WeRelate's Person Pages always display a Christening fact. Baptisms and christening should be entered in the Christening fact, and not entered as the birth date. If there is no birth date, WeRelate will display the christening date on family pages and search results in its place, automatically. It is not useful to specify the birth as "Bef <the baptism>" when you know and have populated the Christening event.

The birth date should not be estimated if there is no source on which to base such as estimate. Some baptism records record the age of the child at baptism, and a birth may be calculated in this case. But to enter a birth date guessed to be some arbitrary period before the baptism, and assume the same place, may actually mislead other researchers. If all that is known is the baptism, only enter the baptism.

Similar conventions apply to death, burial and wills. Do not assume anything about a burial unless you have evidence of a burial, meaning probably at least the cemetery involved. All people are capable of guessing that a burial occurred shortly after death, probably near the location of the death, so it is not useful to provide those kind of estimates without evidence. Do not use the date of will as the date of death. The date of a will may be useful for constraining the death date when the actual date is unknown, as in "Bet 6 Jun 1779 And 13 Sep 1779", but wills are often written years before death, and it is not uncommon for probate to be delayed several years after death.

Likewise, do not use the marriage bann, or intention, in place of the marriage date. Using "Add event/fact", you may enter a fact type called "Marriage Banns".


  • All facts need to be supported by sources and dates are no exception.
  • Sources should identify where the entered date came from. The text of the source should explicitly give the date that the source supports, since the date entered in the date field itself may be changed in the future, making source reference become confusing and inaccurate.

Sources should give the date in the literal form found, and if this requires a non-trivial conversion before it may be entered into WeRelate, the converted form enclosed in square brackets, possibly with comments. Non-trivial conversions would include adding information gleaned from context, all-numeric dates, dates expressed using holidays or other descriptive terms (such as Michelmas, or "ult."), calendar shift conversion, or pretty much anything more elaborate than rearranging terms or abbreviating the month. For example, 6 (6) 66 [6 Aug 1666] would indicate the source gave the date as "6 (6) 66" which you interpreted as 6 Aug 1666. (This is an example of so-called "Quaker dating" discussed under #Month Number and Double Dating below). This format makes it very clear exactly what information the source supports, and what information came from your conversion of the raw source, so that, if necessary, conversion issues may be discussed.

New Style Versus Old Style

The shift from the Julian calendar to the Gregorian calendar has little impact in everyday lives, but is well within the reach of even casual genealogists. This shift resulted in skipping several days to correct for error in leap year handling. Unfortunately, it was adopted at different times in different countries. In the American colonies, ruled by England, the change took place in 1752, when 2 Sep 1752 was followed by 14 Sep 1752, representing a skip of 11 days. (See [1]) Complicating matters, the shift should only be 10 days for dates preceding 1700.

  • Enter the contemporaneous date into WeRelate. Do not use the modern equivalent nor adjust for the 10 or 11 (or other shift amount) date shift.

Some small number of genealogists believe that all dates should be converted to their modern equivalents to ease calculations spanning the switch-over. However, that leads to ambiguity when looking at a date, and one must analyze each date completely to see which convention was used by that author. Additionally, it is easy to make an error doing this conversion. Therefore, it is simpler and more intuitive to use the default style and rely on genealogical knowledge of the reader to realize that dates before 3 Sep 1752 are old-style and dates after 13 Sep 1752 are new-style.

It is conventional to enter "OS" or "NS" as a suffix when the date is given in a non-default style. However, I believe any such suffix, while preserved, would be ignored by WeRelate software that happens to compare dates. So when contemporaneous sources use styles that were not the default for their time period, it is probably beneficial to convert such dates to their default style, before entering into WeRelate, rather than enter OS or NS. (Make sure to document the conversion. See the comment in the #Sources section about date conversion.)

Month Number and Double Dating

In the United States (and England), a potentially more troublesome issue introduced by the calendar shift was the change of the beginning of the year from 25 Mar to 1 Jan. Prior to 1753, the days from 1 Jan to 24 Mar were considered the end of the previous year. The first month of the year was Mar, and Feb was the 12th month. The example date conversion given in the #Sources section shows the sixth month being converted to August since the date occurred before 1753.

The shift in the beginning of the year causes ambiguity in dates that fall in this period of the year. If one is using the style of date that was contemporaneous, 17 Feb 1717 would occur in the year we now consider 1718. However, if a researcher believes in adjusting dates to their modern equivalent, their use of 17 Feb 1717 would mean a different date. Further, it is common for people that are unfamiliar with this issue to misuse their genealogy software, and end up recording the wrong date. Double-dating is a very simple notational way to indicate exactly to the reader what date is meant and avoid these problems.

  • For added clarity, dates between 1 Jan and 24 Mar prior to 1752 should use double dating, e.g., 17 Feb 1717/18.

If double dating is not used, dates between 1 Jan and 24 Mar, occurring before 1752, will be assumed to belong to the following year, i.e., the assumption is that 17 Feb 1717 is 17 Feb 1717/18.

  • The GEDCOM specification requires that the second year in double-dating be written with two digits, e.g., 14 Jan 1699/00.

Other Countries

[TBD: Need help here!]