Help:Date Conventions


Page status

Revisions as of Dec 2016 are intended to prepare this page for being included in the revised Help. Conventions have been refined as per discussions (or lack of response to suggested changes) on the talk page. Preferred formats are given to guide those who are manually entering/editing data, understanding that alternatives will continue to be used until such time as we can automate the date format.

Wording has been changed in several places to add more detail or to clarify. If you wish to revise further (to either clarify or make a section more concise), please do so.

If you wish to continue a discussion about a convention, please do so on the talk page.

General formatting rules for dates

The preferred format for dates is d Mmm yyyy (e.g., 4 Sep 1753). Fully numeric dates (e.g., 9/3/1876) are not allowed, as there is far too much ambiguity inherent. If the record of the event uses numeric dates, it should be converted and entered in the preferred format. (See the discussion of conversion in Sources, below).

Years 1000 or later should always be expressed with 4 digits (e.g., "1753"). Years before 1000 should be expressed with three digits (e.g., "953"), keeping in mind that events before 700 are out of scope for WeRelate.

Source citations for dates should give the date as expressed in the source. This is especially important if any interpretation of the source date was required (e.g., if the source is a fully numeric date).

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". While title case ("Jan") is preferred, all upper case ("JAN") and all lower case ("jan") are both acceptable.


Dates should be made as precise as is known. However, to paraphrase the GEDCOM specification, an imprecise date should not be made to look like it is precise. When a date is not known precisely, the appropriate qualifier should be used to indicate what is known and with what precision, as an aid to subsequent researchers.

While we can no longer trust many sources that identify the year an event took place without indicating how they know that is true, we should not perpetuate the problem by using dates without qualifiers when we do not know the precise date, month or year.

The preferred capitalization for qualifiers is an initial capital (and no capital on the second word of a pair of qualifiers such as "Bet/and"). However, all upper case and all lower case may also be used. Periods should not be used.

The use of a qualifier usually requires a note to explain how the date was arrived at, unless the imprecise date was taken literally from the cited source.


The qualifier "Bef" may be used to indicate that an event occurred on or before the indicated date. 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 on or after the indicated date. For example, if a person acknowledged a deed on 22 Apr 1704, their death date would be Aft 22 Apr 1704.


The qualifier pair "Bet ... and ..." may be used to indicate that two known dates define a window within which an 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.


The qualifier "Cal" should be used when a date has been calculated by adding or subtracting an exact number of years, months and days from a precise date. The use of "Cal" informs the reader that the date was derived and not found in a source. This is important because the information used for the calculation (e.g., age at death) might not be correct (even when expressed with year/month/day precision), and because the person doing the calculation might not know which convention the source used to determine the number of days between two dates (e.g., inclusive of both dates vs. exclusive of the starting date).

By using the qualifier "Cal", you indicate that the calculated date is the best information you have, but it is possible that it is not accurate. A later researcher would then know that they could replace the calculated date with a date taken from a primary source (e.g., the person's birth record) that provides the date directly.

"Cal" should only be used when there is a known date and a known time span (precise to the number of days) to use in calculating a date, and not when the date is estimated based only on a known date or an imprecise time span. For example, since people get married at different ages, any birth date derived from the marriage date must be estimated, not calculated. If an age is given but is expressed only in years, it is more appropriate to use the qualifier "Abt" (see below).


In the absence of sources to reliably establish a person's birth year, it is often useful to at least approximate a birth year in order to distinguish between others of the same name, or to establish a timeline in order to do feasibility assessments. The qualifier "Est" is used for such an approximation. Such estimates include only the year because they are understood to potentially be off by a few years (or even several years when the information is very sparse).

For example, if a person is married in 1805 and soon has children, it would be appropriate to list their birth as Est 1780.

Since any estimate is based on one or more underlying assumptions (such as typical age at first marriage, typical gap between births within a family, or average gap between generations), all estimates should have a note explaining how the estimate was arrived at.

When the assumption used to estimate a birth year is almost certain to be true (such as the assumption that a person was of legal age when they bought land, or the assumption that a person assigned to a guardian was under legal age), another qualifier such as "Bef" or "Aft" may be more appropriate. For example, if a colonial man bought property 17 Jul 1687, the birth date could be expressed as Bef 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.

Note that it is usually not helpful to estimate dates other than birth dates. This is because estimates can be less accurate than intended, which can mislead future researchers. They can also result in unnecessary warning messages (such as a person born before their parents estimated marriage year). Dates should only be estimated when they serve a purpose such as distinguishing between people of the same name or establishing an inter-generational timeline. In particular, it is not necessary to estimate marriage dates in order to have multiple marriages display in the correct order in WeRelate (they can be manually reordered on the person page).


The qualifier "Abt" should be used when a year (or, occasionally, a year and month) is calculated from a known date and time span where either the known date or the time span (or both) are not precise to the day. The most common example of this is when the birth year is derived from an age expressed in years. "Abt" is used because it is possible for the person to have been born in the year calculated as "known year - age" or in the previous year. Another example would be a marriage year derived from the number of years married.

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.

To communicate as precisely as possible, other qualifiers should be used in preference to "Abt" whenever they apply. For example, a vital record that 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.

The GEDCOM specification defines "ABT" to be an inexact date. In practice, "ABT" has been used indiscriminately for any type of imprecise date. Hence, it has developed some ambiguity as to the reliability of the date it qualifies, ranging from wild guesses to fairly solid calculated dates. For this reason, if "Abt" is used, the source citation should clearly indicate how precise and reliable the approximation is.


The qualifier pair "From ... to ..." is used to indicate a time period (inclusive) over which something was always true (as opposed to "Bet ... and ..." which identifies a date range within which a discrete event happened). Thus, "From ... to ..." may be used with some of the auxiliary fact types such as residence, occupation and education, as opposed to the main genealogy events of birth, marriage and death, which are discrete events.

Using "From <date>" or "To <date>" (without specifying the other end of the time period) is allowed.

Note that the GEDCOM specification does not allow combining of From/to with Abt or Est. For this reason, when the "from" or "to" date is expressed as a year, there is no indication of whether or not the year is meant to be an approximation.

Interpreted (not to be used)

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.

Proxy dates

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

Like many genealogy applications, WeRelate treats christening date as a proxy for birth date when only the christening date is known, and burial date as a proxy for death date when only the burial date is known. Therefore, if only the christening date is known, nothing should be entered into the birth date field (neither the christening date nor a guess based on an arbitrary number of days before the christening, which could mislead other researchers). Similarly, if only the burial date is known, nothing should be entered into the death date field.

On the other hand, if the christening record indicates the age of the child, to the day, the birth date can be calculated and put in the birth date field with the qualifier "Cal".

When a christening or burial date is used as a proxy, do not enter a birth or death date that can be derived from the proxy (e.g., Bef christening date). Entering anything into the birth or death date field will prevent WeRelate from using the christening or burial date as a proxy on display screens, giving other researchers less information than an exact christening or burial date.

Again, to avoid misleading other researchers, do not assume that a person was born where they were baptized, or died where they were buried. Note also that entering a birth place will prevent WeRelate from using the christening date as a proxy for birth date and entering a death place will prevent WeRelate from using the burial date as a proxy for death date.

Note that in addition to the christening date, WeRelate also has a baptism fact. For groups of people that practice adult baptism (e.g., Baptists, Mennonites), the baptism fact should be used instead of the christening fact, so that the baptism date does not serve as a proxy for birth date. As well, when it is clear from a record that a person was baptized as an adult (or even as an older child), the baptism fact should be used instead of the christening field.

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 so that credibility may be assessed by the WeRelate community. 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 switch 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 switch resulted in skipping several days to correct for an error in leap year handling. Unfortunately, the Gregorian calendar 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 Old Style and New Style dates). Complicating matters, the shift is only 10 days for dates preceding 1700.

When entering Julian ("old style") dates, enter the contemporaneous date. Do not use the modern equivalent by adjusting for the 10 or 11 day (or other amount) 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 American dates before 3 Sep 1752 are old-style and after 13 Sep 1752 are new-style. (See Wikipedia for when other countries switched.)

If it is known that a contemporaneous source used a style that was not the default for their time period (e.g., if it appended OS for old-style or NS for new-style when that was not the default of the time), convert the date to the default style of the time. (Make sure to document in the source citation the date as it was written and the conversion applied. 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 switch from the Julian calendar to the Gregorian calendar was the change of the beginning of the year from 25 March to 1 January. Prior to 1752, the days from 1 January to 24 March were considered the end of the previous year. The first month of the year was March, and February 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 1752. 1751 was the last year to use old month numbers. It was a short year containing only 282 days, from 25 Mar. to 31 Dec. 31. 1752 was the first year to begin on January 1st and use modern month numbering.

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 record the wrong date. Double dating is a very simple notation to indicate to the reader exactly what date is meant and avoid these problems.

Double dating (also known as split-year dating) involves explicitly including both the contemporaneous year and the year according to the Gregorian calendar. This is only applicable to dates that fall between 1 Jan and 24 Mar (prior to 1752 in the United States and England). The format for a double date is d Mmm yyyy/yy (e.g., 17 Feb 1717/18, 14 Jan 1699/00). 1750/51 would be the last needed use of double-dating.

Note that if you are using a secondary source (e.g., a published genealogy) it is probably safest not to add double dating to a pre-1752 date, unless the author has made it clear whether or not they are adjusting dates. This is because the author may have already adjusted the date and you would end up applying the adjustment twice. Genealogical websites are full of dates that have been adjusted not once but 2, 3 or even 4 times, resulting in dates that are several years away from when the event actually took place. If you have other information that makes you confident which year the event took place (e.g., a mother did not die before her child was born), it is okay to double date, but otherwise, you may mislead other researchers by doing so.

If double dating is not used, WeRelate software assumes that dates between 1 Jan and 24 Mar, occurring before 1752 (in the U.S. and England), belong to the following year. For example, WeRelate will assume that 17 Feb 1717 is 17 Feb 1717/18.

Other calendars

There are, as yet, no WeRelate conventions for handling calendars other than the Julian and the Gregorian. Anyone wishing to develop conventions for other calendars, such as Chinese or Japanese dating systems, is welcome to do so.