This is my scratchpad for trying out things...

DRAFT COPY - NOT READY FOR USE

Step 1: Go to the Add a Person page

Finding the Add a Person page
When adding the first person in a tree
From any page: Go to Add a Person page by selecting Add > Person from dropdown in top menu	Example: Add a new person from any page
When adding a parent or spouse
From a Family page: If the name exists at the top of the page, Go to Add a Person page by selecting (add) by the name If the name does not exist at the top of the page, Open page in edit mode by selecting Edit from the left menu Go to Add a Person page by selecting Add a page for (wife or husband)	Example: Add spouse to Family page directly from Family page	Example: Add spouse to Family page in edit mode
From a Person page: If the name exists on the right side of the page, Go to Add a Person page by selecting (add) by the name If the name does not exist, but the correct Family page does, Open the Family page in edit mode by selecting (edit) under the page link Go to Add a Person page by selecting Add a page for (wife or husband) If neither the name nor the correct Family page exist, you must first add the correct Family page, see How to add a new Family page	Example: Add spouse to Family page directly from Person page	Example: Opening Family page in edit mode from Person page Example: Add spouse to Family page in edit mode
When adding a child
From a Family page: Select Add child	Example: Add child to Family page directly from Family page

Step 2: Enter the data on the Add a Person page

The Add a Person page has fields for entering a person's name, gender, birth and death information to check the database for a matching page or to populate the fields for a new page when there is no match.

Example of the data entry box on an Add a Person page.

Enter only known information into these fields, as completely as possible. Leave unknown information blank.

The Given name field

For the primary name (name at birth), enter first and all middle name(s). Don't include nicknames (which are entered as alternate names).

• When a full name is known, enter it in full. Don't use an abbreviation (e.g., Wm) even if the source does.
• Initials are acceptable if the full name is unknown or when recognized as part of the legal name. Enter them without periods. Separate multiple initials with single spaces (e.g., R J).

Use mixed case. Never use all capital letters.
Characters with accents and diacritics may be used (e.g., Bjørn, Françoise).
Punctuation may be used only if it is part of the legal name (e.g., Jean-Baptiste).

If the given name is unknown or an infant died without being named, leave the given name blank.

Don't include titles, surnames, numbers, or placeholder words in the given name field.
Don't use quotation marks, slashes, parentheses, or brackets ("",//,(),[],<>) to denote a nickname, alias, or unknown or uncertain name.
Don't use parentheses or brackets to indicate alternate spellings, e.g., Garret(t).

The Surname field

Enter the surname in full, including multiple parts and articles if they exist (e.g., St. Leger, van der Valk).

• Enter the name as it was used by the individual, including abbreviations if applicable (e.g., St. Leger).

Use mixed case. Never use all capital letters.
Characters with accents and diacritics may be used (e.g., Évêque, François).
Punctuation may be used only if it is part of the legal name (e.g., O'Neill, 't Gilde).

If the surname is unknown, leave the surname blank.

Don't include titles, given names, numbers, or placeholder words in the surname field.
Don't use quotation marks, slashes, parentheses, or brackets ("",//,(),[],<>) to denote an alias or unknown or uncertain name.
Don't use parentheses or brackets to indicate alternate spellings, e.g., Ro(o)ij.

Gender

Use the dropdown menu to specify gender.

Fact type

Use the dropdown menu to specify a fact type for each row. There are four options at this stage: Birth, Christening (Infant Baptism), Death, or Burial. Additional facts can be added later in the process.

The Date field

Quick reference

Further information

Date format

Standard format

WeRelate dates are in d Mmm yyyy format (e.g., 4 Sep 1753) with modifier(s) (e.g., Bef, Aft) as applicable. Dual dates are expressed as d Mmm yyyy/yy.

WeRelate automatically formats dates into standard format whenever it can interpret them. That is, you can enter dates in upper or lower case, with or without leading zeroes, and with full month names or abbreviations, and WeRelate transforms them into standard format. Be cautious, however, about entering dates with ambiguous meanings, such as 1853-1860 (WeRelate may interpret this as From 1853 to 1860 when your intent may have been Bet 1853 and 1860).

Dual dates must be entered with a slash (/) not a dash (-).

Dates may include text within parentheses, either as the sole content of the date field, or after the date. WeRelate preserves this text but ignores it when sorting or searching. Recommended usage of text phrases (when the actual date is unknown):

• (in infancy) - can be used when a child died within a year or two of birth
• (young) - can be used when a child died before marriageable age

For dates requiring a non-trivial conversion or interpretation from the source (e.g., where the source says "4 5 1658" or "last of Sept"), the source text can be placed in parentheses after the formatted date, e.g., 4 Jul 1658 (4 5 1658). However, the WeRelate convention is that the original text be placed in the source citation instead - see the discussion in Sources below.

Unacceptable dates

Any date that WeRelate cannot interpret is unacceptable. This includes:

• fully numeric dates (e.g., 9/3/1876) where the day is 1-12
• date ranges with incomplete years, such as 1954-55
• date ranges or alternatives expressed with a slash, such as 4/6 Sep 1856
• incorrect spelling of the month or abbreviation, such as Octobr or Oc
• phrases such as "at age 16" unless they are in parentheses
• "unknown" (WeRelate will automatically blank this out)

Other dates are also unacceptable, even though WeRelate can interpret them. These include:

• WFT Est date ranges (algorithm-generated date ranges)
• date ranges in which the start date is after the end date (e.g., From 1845 to 1790)
• invalid dates, such as 31 Apr 1768
• dual dates after 1752

Language support

WeRelate can interpret month names and abbreviations and some (but not all) modifiers in a few other languages (Dutch, German, French, Spanish, Norwegian, Danish, and Portuguese as of June 2024). These are transformed to English for storage, but if you choose to display the WeRelate site in another language (an option in your settings), the month abbreviations are displayed in that language. (WeRelate does not currently display modifiers in other languages.)

Month abbreviations

WeRelate uses and can interpret standard 3-character month abbreviations, as follows:

• English: "Jan", "Feb", "Mar", "Apr", "May", Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
• Dutch: "jan", "feb", "mrt", "apr", "mei", jun", "jul", "aug", "sep", "okt", "nov", "dec"
• German: "Jan", "Feb", "Mär", "Apr", "Mai", Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"
• French: "jan", "fév", "mar", "avr", "mai", jun", "jul", "aoû", "sep", "oct", "nov", "déc"
• Spanish: "ene", "feb", "mar", "abr", "may", jun", "jul", "ago", "sep", "oct", "nov", "dic"
• Norwegian: "jan", "feb", "mar", "apr", "mai", "jun", "jul", "aug", "sep", "okt", "nov", "des"
• Danish: "jan", "feb", "mar", "apr", "maj", "jun", "jul", "aug", "sep", "okt", "nov", "dec"
• Portuguese: "jan", "fev", "mar", "abr", "mai", "jun", "jul", "ago", "set", "out", "nov", "dez"

Accented characters can be entered without the accent and WeRelate will still understand the abbreviation.

Modifiers

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 modifier should be used to indicate what is known and with what precision, as an aid to subsequent researchers.

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

The GEDCOM specification defines several modifiers but provides little information on their proper usage. WeRelate asks that users follow the conventions below, developed after careful consideration of best practice.

Before

The modifier "Bef" is used to indicate that an event occurred on or before the indicated date. For example, if a will dated 15 Jun 1863 refers to a deceased neighbor, the death date of the neighbor would be specified as Bef 15 Jun 1863.

After

The modifier "Aft" is 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.

Between/and

The modifier pair "Bet ... and ..." is 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.

From/to

The modifier pair "From ... to ..." is used to indicate a time period (inclusive) over which something was always true (as opposed to "Bet ... and ..." which identifies an interval within which an event happened). Thus, "From ... to ..." may be used with fact types such as residence, occupation, education and military service, which can extend over a period of time, as opposed to the main genealogy events of birth, marriage and death, which cannot.

"From" and "to" can each be used on their own, to indicate that an event (such as occupation) extended over a period of time, but for which the end date (when using "From ...") or the start date (when using "To ...") is not known.

Calculated

The modifier "Cal" is used when a precise 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 modifier "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 precise 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 on an imprecise time span. For example, since people get married at different ages, any birth date derived from the marriage date is estimated, not calculated. If an age is given but is expressed only in years, use the modifier "Abt" instead of "Cal".

About

The modifier "Abt" is 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 modifiers 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 is not clear on whether "abt" is acceptable together with other modifiers (e.g., "Bet abt ... and abt ..."). However, since other genealogy software accepts these combinations, and there are times when exact date ranges are unknown, WeRelate also allows "abt" to be used as follows: "Bef abt ...", "Aft abt ...", "Bet abt ... and abt ...", "From abt ... to abt ...".

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 modifies, 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.

Estimated

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 people of the same name, or to establish a timeline in order to do feasibility assessments. The modifier "Est" is used for such an approximation. Such estimates include only the year because they could be off by a few years (or even decades when the information is very sparse).

For example, if a person is married in 1805 and has children soon after, 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 modifier 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). In particular, it isn't necessary to estimate marriage dates in order to show multiple marriages in the correct order, since WeRelate allows you to manually reorder marriages. However, depending on the information available, it may be more feasible to estimate a marriage year than the birth year of either spouse. In this case, the marriage year should be estimated to provide useful information in search results.

Interpreted (not to be used)

The "INT" modifier 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. For example, if the source says "last of Sept 1723", the date can be entered as 30 Sep 1723 (without the Int modifier), with the original phrase included in the source citation.

Proxy dates

Like many genealogy applications, WeRelate treats christening date as a proxy for birth date when the birth date is unknown, and burial date as a proxy for death date when the death date is unknown. WeRelate conventions for proxy dates are as follows:

• Do not put a proxy date in the field (birth or death date) it is a proxy for. Instead, put proxy dates in their own fields. That is, enter a christening date in the christening date field and a burial date in the burial date field.
• Do not make assumptions about birth date or place based on christening date and place, nor about death date or place based on burial date and place, to avoid misleading other researchers. When only a proxy date is known, do not enter anything in the event it is a proxy for. If you enter a date or place in birth or death fields, it prevents WeRelate from displaying the proxy date in search results and at the top of the Person page, giving other researchers less information than an exact christening or burial date.

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 modifier "Cal".

• In addition to the christening fields, WeRelate also has a baptism event (use "Add event/fact" to add it). If there is no birth or christening information, WeRelate uses the baptism date as a proxy for the birth date.

For groups of people that practice adult baptism (e.g., Baptists, Mennonites), the baptism event should be used instead of the christening event because "christening" implies the naming of an infant. 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 event should be used instead of the christening event. This will signal to other researchers that the person may not have been born within months of the baptism date.

If there is no birth or christening date and it is inappropriate to use the baptism date as a proxy for birth date, add an estimated birth year.

• Just as burial date and place should be allowed to stand on their own when the death date is unknown, death date and place shouldn't be used to derive burial date and place. 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 (and may be misleading) to provide those kind of estimates without evidence. Only enter burial date and/or place if you can provide evidence for the exact date and/or the place.

Similar conventions apply to other dates that WeRelate doesn't use as proxies:

• Do not use the date of will as the date of death. The dates of a will and/or estate inventory or probate may be useful for constraining the death date when the actual death 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, so these should never be used as the death date.

• Likewise, do not enter a marriage banns or intention date as a marriage date. Using "Add event/fact", add an event called "Marriage Banns" and enter the date there.

Sources

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 date came from. The text of the source should explicitly give the date that the source supports, in case the date entered in the date field is changed in the future.

Sources should give the date in the literal form found, and if this requires a non-trivial conversion to standard WeRelate format, 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 dual dating

In the same year that England and the American Colonies switched from the Julian calendar to the Gregorian calendar, they also moved the start of the year from 25 March (which it had been in England since the 12th century) 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. Starting in 1752, the year began on 1 January. The example date conversion given in the Sources section shows the sixth month being converted to August since the date occurred before 1752.

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

Dual dating (also known as split-year dating or double 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 dual date is d Mmm yyyy/yy (e.g., 17 Feb 1717/18, 14 Jan 1699/00).

Note that if you are using a secondary source (e.g., a published genealogy) it is probably safest not to add dual 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 dual date, but otherwise, you may mislead other researchers by doing so.

WeRelate never automatically transforms a single year into a dual year. For a pre-1752 date between January and March, if dual dating is not entered by the user, WeRelate takes the year at face value, essentially treating it as if it has already been adjusted. If the user enters a dual date, WeRelate sorts using the latter year (e.g., 1721/22 is treated as if it were 1722).

Other calendars

There are no WeRelate conventions for handling calendars other than the Julian and the Gregorian.

The Place field

[cos1776 note: I have not made a convention card for this, so the other format is included here for now.]

Enter the place name in the following format (for places in the United States): Municipality or Township, County, State, United States. Do not enter the words "Township" or "County". Enter only what is known - e.g., if the municipality is not known, start with the township, county or country.

Once you enter a comma, pause a few seconds and WeRelate will present a dropdown of potential matches. Select a match or continue typing to refine the dropdown. You can skip a part of the place name - for example, you can enter municipality, state to get a list of all places with that municipality name in that state - then select from the list. Note: WeRelate matches on exactly what is typed, so spelling matters; however, capitalization does not.

For further information, see how to select a place. For further information, see How to select a place name.

Step 3: Search for possible matches

Once you have entered as much information as is known on the Add a Person page, click Next to run a Search for possible matches.

From the Search page, scan the results to see if a match exists:

• If there is no match, click Add Page to open the new page in Edit mode where sources and additional information can be added. See How to edit a Person page for instructions.
• If there is a match, DO NOT click Add Page, but rather click Select next to the matching page title to open the existing page in edit mode where sources and additional information can be added. See How to edit a Person page for instructions.
• If there might be a match (i.e., you are not certain), review any page in the list by clicking directly on the page title (not the Select button). After reviewing, use your browser's back arrow to return to the Search for possible matches page again, and either Select the match or Add Page if there was no match.

Note: Please err on the side of caution. It is better to add a new page and have two pages for the same person until research can determine a match than it is to have one page that mixes the information for two different people. The latter causes considerable confusion and can be difficult to untangle.

Related pages

• How to edit an existing Person page

How to add the first person in a tree

Example: Add a new person from any page

Step 1: Go to the Add a Person page

• Select Add > Person from the dropdown menu at the top of any page.

Step 2: Enter information

Example: Entry box from Add a Person page

The Add a Person page has fields for entering a person's name, gender, birth and death information to check the database for a matching page or to populate the fields for a new page when there is no match.

Enter only known information into these fields, as completely as possible. Leave unknown information blank.

The Given name field

For the primary name (name at birth), enter first and all middle name(s). Don't include nicknames (which are entered as alternate names).

• When a full name is known, enter it in full. Don't use an abbreviation (e.g., Wm) even if the source does.
• Initials are acceptable if the full name is unknown or when recognized as part of the legal name. Enter them without periods. Separate multiple initials with single spaces (e.g., R J).

Use mixed case. Never use all capital letters.
Characters with accents and diacritics may be used (e.g., Bjørn, Françoise).
Punctuation may be used only if it is part of the legal name (e.g., Jean-Baptiste).

If the given name is unknown or an infant died without being named, leave the given name blank.

Don't include titles, surnames, numbers, or placeholder words in the given name field.
Don't use quotation marks, slashes, parentheses, or brackets ("",//,(),[],<>) to denote a nickname, alias, or unknown or uncertain name.
Don't use parentheses or brackets to indicate alternate spellings, e.g., Garret(t).

The Surname field

Enter the surname in full, including multiple parts and articles if they exist (e.g., St. Leger, van der Valk).

• Enter the name as it was used by the individual, including abbreviations if applicable (e.g., St. Leger).

Use mixed case. Never use all capital letters.
Characters with accents and diacritics may be used (e.g., Évêque, François).
Punctuation may be used only if it is part of the legal name (e.g., O'Neill, 't Gilde).

If the surname is unknown, leave the surname blank.

Don't include titles, given names, numbers, or placeholder words in the surname field.
Don't use quotation marks, slashes, parentheses, or brackets ("",//,(),[],<>) to denote an alias or unknown or uncertain name.
Don't use parentheses or brackets to indicate alternate spellings, e.g., Ro(o)ij.

Gender

Use the dropdown menu to specify gender.

Fact type

Use the dropdown menu to specify a fact type for each row. There are four options at this stage: Birth, Christening (Infant Baptism), Death, or Burial. Additional facts can be added later in the process.

The Date field

Quick reference

Further information

Date format

Standard format

WeRelate dates are in d Mmm yyyy format (e.g., 4 Sep 1753) with modifier(s) (e.g., Bef, Aft) as applicable. Dual dates are expressed as d Mmm yyyy/yy.

WeRelate automatically formats dates into standard format whenever it can interpret them. That is, you can enter dates in upper or lower case, with or without leading zeroes, and with full month names or abbreviations, and WeRelate transforms them into standard format. Be cautious, however, about entering dates with ambiguous meanings, such as 1853-1860 (WeRelate may interpret this as From 1853 to 1860 when your intent may have been Bet 1853 and 1860).

Dual dates must be entered with a slash (/) not a dash (-).

Dates may include text within parentheses, either as the sole content of the date field, or after the date. WeRelate preserves this text but ignores it when sorting or searching. Recommended usage of text phrases (when the actual date is unknown):

• (in infancy) - can be used when a child died within a year or two of birth
• (young) - can be used when a child died before marriageable age

For dates requiring a non-trivial conversion or interpretation from the source (e.g., where the source says "4 5 1658" or "last of Sept"), the source text can be placed in parentheses after the formatted date, e.g., 4 Jul 1658 (4 5 1658). However, the WeRelate convention is that the original text be placed in the source citation instead - see the discussion in Sources below.

Unacceptable dates

Any date that WeRelate cannot interpret is unacceptable. This includes:

• fully numeric dates (e.g., 9/3/1876) where the day is 1-12
• date ranges with incomplete years, such as 1954-55
• date ranges or alternatives expressed with a slash, such as 4/6 Sep 1856
• incorrect spelling of the month or abbreviation, such as Octobr or Oc
• phrases such as "at age 16" unless they are in parentheses
• "unknown" (WeRelate will automatically blank this out)

Other dates are also unacceptable, even though WeRelate can interpret them. These include:

• WFT Est date ranges (algorithm-generated date ranges)
• date ranges in which the start date is after the end date (e.g., From 1845 to 1790)
• invalid dates, such as 31 Apr 1768
• dual dates after 1752

Language support

WeRelate can interpret month names and abbreviations and some (but not all) modifiers in a few other languages (Dutch, German, French, Spanish, Norwegian, Danish, and Portuguese as of June 2024). These are transformed to English for storage, but if you choose to display the WeRelate site in another language (an option in your settings), the month abbreviations are displayed in that language. (WeRelate does not currently display modifiers in other languages.)

Month abbreviations

WeRelate uses and can interpret standard 3-character month abbreviations, as follows:

• English: "Jan", "Feb", "Mar", "Apr", "May", Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
• Dutch: "jan", "feb", "mrt", "apr", "mei", jun", "jul", "aug", "sep", "okt", "nov", "dec"
• German: "Jan", "Feb", "Mär", "Apr", "Mai", Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"
• French: "jan", "fév", "mar", "avr", "mai", jun", "jul", "aoû", "sep", "oct", "nov", "déc"
• Spanish: "ene", "feb", "mar", "abr", "may", jun", "jul", "ago", "sep", "oct", "nov", "dic"
• Norwegian: "jan", "feb", "mar", "apr", "mai", "jun", "jul", "aug", "sep", "okt", "nov", "des"
• Danish: "jan", "feb", "mar", "apr", "maj", "jun", "jul", "aug", "sep", "okt", "nov", "dec"
• Portuguese: "jan", "fev", "mar", "abr", "mai", "jun", "jul", "ago", "set", "out", "nov", "dez"

Accented characters can be entered without the accent and WeRelate will still understand the abbreviation.

Modifiers

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 modifier should be used to indicate what is known and with what precision, as an aid to subsequent researchers.

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

The GEDCOM specification defines several modifiers but provides little information on their proper usage. WeRelate asks that users follow the conventions below, developed after careful consideration of best practice.

Before

The modifier "Bef" is used to indicate that an event occurred on or before the indicated date. For example, if a will dated 15 Jun 1863 refers to a deceased neighbor, the death date of the neighbor would be specified as Bef 15 Jun 1863.

After

The modifier "Aft" is 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.

Between/and

The modifier pair "Bet ... and ..." is 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.

From/to

The modifier pair "From ... to ..." is used to indicate a time period (inclusive) over which something was always true (as opposed to "Bet ... and ..." which identifies an interval within which an event happened). Thus, "From ... to ..." may be used with fact types such as residence, occupation, education and military service, which can extend over a period of time, as opposed to the main genealogy events of birth, marriage and death, which cannot.

"From" and "to" can each be used on their own, to indicate that an event (such as occupation) extended over a period of time, but for which the end date (when using "From ...") or the start date (when using "To ...") is not known.

Calculated

The modifier "Cal" is used when a precise 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 modifier "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 precise 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 on an imprecise time span. For example, since people get married at different ages, any birth date derived from the marriage date is estimated, not calculated. If an age is given but is expressed only in years, use the modifier "Abt" instead of "Cal".

About

The modifier "Abt" is 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 modifiers 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 is not clear on whether "abt" is acceptable together with other modifiers (e.g., "Bet abt ... and abt ..."). However, since other genealogy software accepts these combinations, and there are times when exact date ranges are unknown, WeRelate also allows "abt" to be used as follows: "Bef abt ...", "Aft abt ...", "Bet abt ... and abt ...", "From abt ... to abt ...".

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 modifies, 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.

Estimated

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 people of the same name, or to establish a timeline in order to do feasibility assessments. The modifier "Est" is used for such an approximation. Such estimates include only the year because they could be off by a few years (or even decades when the information is very sparse).

For example, if a person is married in 1805 and has children soon after, 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 modifier 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). In particular, it isn't necessary to estimate marriage dates in order to show multiple marriages in the correct order, since WeRelate allows you to manually reorder marriages. However, depending on the information available, it may be more feasible to estimate a marriage year than the birth year of either spouse. In this case, the marriage year should be estimated to provide useful information in search results.

Interpreted (not to be used)

The "INT" modifier 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. For example, if the source says "last of Sept 1723", the date can be entered as 30 Sep 1723 (without the Int modifier), with the original phrase included in the source citation.

Proxy dates

Like many genealogy applications, WeRelate treats christening date as a proxy for birth date when the birth date is unknown, and burial date as a proxy for death date when the death date is unknown. WeRelate conventions for proxy dates are as follows:

• Do not put a proxy date in the field (birth or death date) it is a proxy for. Instead, put proxy dates in their own fields. That is, enter a christening date in the christening date field and a burial date in the burial date field.
• Do not make assumptions about birth date or place based on christening date and place, nor about death date or place based on burial date and place, to avoid misleading other researchers. When only a proxy date is known, do not enter anything in the event it is a proxy for. If you enter a date or place in birth or death fields, it prevents WeRelate from displaying the proxy date in search results and at the top of the Person page, giving other researchers less information than an exact christening or burial date.

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 modifier "Cal".

• In addition to the christening fields, WeRelate also has a baptism event (use "Add event/fact" to add it). If there is no birth or christening information, WeRelate uses the baptism date as a proxy for the birth date.

For groups of people that practice adult baptism (e.g., Baptists, Mennonites), the baptism event should be used instead of the christening event because "christening" implies the naming of an infant. 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 event should be used instead of the christening event. This will signal to other researchers that the person may not have been born within months of the baptism date.

If there is no birth or christening date and it is inappropriate to use the baptism date as a proxy for birth date, add an estimated birth year.

• Just as burial date and place should be allowed to stand on their own when the death date is unknown, death date and place shouldn't be used to derive burial date and place. 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 (and may be misleading) to provide those kind of estimates without evidence. Only enter burial date and/or place if you can provide evidence for the exact date and/or the place.

Similar conventions apply to other dates that WeRelate doesn't use as proxies:

• Do not use the date of will as the date of death. The dates of a will and/or estate inventory or probate may be useful for constraining the death date when the actual death 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, so these should never be used as the death date.

• Likewise, do not enter a marriage banns or intention date as a marriage date. Using "Add event/fact", add an event called "Marriage Banns" and enter the date there.

Sources

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 date came from. The text of the source should explicitly give the date that the source supports, in case the date entered in the date field is changed in the future.

Sources should give the date in the literal form found, and if this requires a non-trivial conversion to standard WeRelate format, 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 dual dating

In the same year that England and the American Colonies switched from the Julian calendar to the Gregorian calendar, they also moved the start of the year from 25 March (which it had been in England since the 12th century) 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. Starting in 1752, the year began on 1 January. The example date conversion given in the Sources section shows the sixth month being converted to August since the date occurred before 1752.

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

Dual dating (also known as split-year dating or double 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 dual date is d Mmm yyyy/yy (e.g., 17 Feb 1717/18, 14 Jan 1699/00).

Note that if you are using a secondary source (e.g., a published genealogy) it is probably safest not to add dual 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 dual date, but otherwise, you may mislead other researchers by doing so.

WeRelate never automatically transforms a single year into a dual year. For a pre-1752 date between January and March, if dual dating is not entered by the user, WeRelate takes the year at face value, essentially treating it as if it has already been adjusted. If the user enters a dual date, WeRelate sorts using the latter year (e.g., 1721/22 is treated as if it were 1722).

Other calendars

There are no WeRelate conventions for handling calendars other than the Julian and the Gregorian.

The Place field

[cos1776 note: I have not made a convention card for this, so the other format is included here for now.]

Enter the place name in the following format (for places in the United States): Municipality or Township, County, State, United States. Do not enter the words "Township" or "County". Enter only what is known - e.g., if the municipality is not known, start with the township, county or country.

Once you enter a comma, pause a few seconds and WeRelate will present a dropdown of potential matches. Select a match or continue typing to refine the dropdown. You can skip a part of the place name - for example, you can enter municipality, state to get a list of all places with that municipality name in that state - then select from the list. Note: WeRelate matches on exactly what is typed, so spelling matters; however, capitalization does not.

For further information, see how to select a place. For further information, see How to select a place name.

Step 3: Search for matches

• Once you have entered the information above on the Add a Person page, select Next to run a search to see if there is already a page for this person.

From the Search page, scan the results to see if a match exists:

• If there is no match, click Add Page to open the new page in Edit mode where sources and additional information can be added. See How to edit a Person page for instructions.
• If there is a match, DO NOT click Add Page, but rather click Select next to the matching page title to open the existing page in edit mode where sources and additional information can be added. See How to edit a Person page for instructions.
• If there might be a match (i.e., you are not certain), review any page in the list by clicking directly on the page title (not the Select button). After reviewing, use your browser's back arrow to return to the Search for possible matches page again, and either Select the match or Add Page if there was no match.

Note: Please err on the side of caution. It is better to add a new page and have two pages for the same person until research can determine a match than it is to have one page that mixes the information for two different people. The latter causes considerable confusion and can be difficult to untangle.

How to add a person to an existing tree

Building a tree involves alternating between adding Person pages and Family pages. A Family page is used to link Person pages together to define a family unit and to enter any information specific to that family unit. Therefore, there is always the potential for a Person page to be linked to one Family page for parents and siblings and to one or more Family pages for each spouse and children.

The easiest way to add a person to an existing tree is from a Family page. See How to add a new Family page, if a new page is needed.

How to add a parent or spouse

Example: Add spouse to Family page directly from Family page

From a Family page:

If the name exists at the top of the page,

• Go to Add a Person page by selecting (add) by the name
• Continue with Step 2:Enter information above.

Example: Add spouse to Family page in edit mode

If the name does not exist at the top of the page,

• Open page in edit mode by selecting Edit from the left menu
• Go to Add a Person page by selecting Add a page for (wife or husband)
• Continue with Step 2:Enter information above.

Example: Add spouse to Family page directly from Person page

From a Person page:

If the name exists on the right side of the page,

• Go to Add a Person page by selecting (add) by the name
• Continue with Step 2:Enter information above.

Example: Opening Family page in edit mode from Person page

If the name does not exist, but the correct Family page does,

• Open the Family page in edit mode by selecting (edit) under the page link

Example: Add spouse to Family page in edit mode

• Go to Add a Person page by selecting Add a page for (wife or husband)
• Continue with Step 2:Enter information above.

If the correct Family page does not exist, you must add it first.

• See How to add a new Family page

How to add a child

Example: Add child to Family page directly from Family page

From a Family page:

• Select Add child
• Continue with Step 2:Enter information above.