Menu
- Home
- Search▼
- List▼
- Add▼
- My Relate▼
- Admin▼
ViewsWatchersPlease Donate |
This is my scratchpad for trying out things...
Step 1: Go to the Add a Person page
Step 2: Enter the data on the Add a Person page
The Given name fieldFor the primary name (name at birth), enter first and all middle name(s). Don't include nicknames (which are entered as alternate names).
Use mixed case. Never use all capital letters. 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.
The Surname fieldEnter the surname in full, including multiple parts and articles if they exist (e.g., St. Leger, van der Valk).
Use mixed case. Never use all capital letters. If the surname is unknown, leave the surname blank. Don't include titles, given names, numbers, or placeholder words in the surname field.
GenderUse the dropdown menu to specify gender. Fact typeUse 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 fieldQuick referenceEnter dates as d mmm yyyy. If appropriate, add a modifier (bef, aft, bet/and, from/to, cal, abt, est). Case doesn't matter - WeRelate automatically transforms dates to mixed-case. WeRelate supports dual dating (d Mmm yyyy/yy) - if you are entering dates prior to 1752 and aren't familiar with dual dating, please read Month number and dual dating. Enter proxy dates (e.g., christening date as proxy for birth date, or burial date as proxy for death date) in their own events (not as birth or death date). When a proxy date is used, do not enter a birth or death date that can be derived from the proxy date (e.g., Bef christening date). Source citations should give the date supported by the source in case the date in the date field is changed. If a non-trivial conversion is required, the source citation should include both the date as expressed in the source and the converted date (e.g., 6 (6) 66 [6 Aug 1666]). Further informationDate formatStandard formatWeRelate 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.
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):
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 datesAny date that WeRelate cannot interpret is unacceptable. This includes:
Other dates are also unacceptable, even though WeRelate can interpret them. These include:
Language supportWeRelate 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 abbreviationsWeRelate uses and can interpret standard 3-character month abbreviations, as follows:
Accented characters can be entered without the accent and WeRelate will still understand the abbreviation. ModifiersDates 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. BeforeThe 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. AfterThe 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/andThe 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.
From/toThe 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. CalculatedThe 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". AboutThe 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. EstimatedIn 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 datesLike 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:
Similar conventions apply to other dates that WeRelate doesn't use as proxies:
SourcesAll 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 StyleThe 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 datingIn 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).
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 calendarsThere 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.
Step 3: Search for possible matchesOnce 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:
Related pagesHow 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
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 fieldFor the primary name (name at birth), enter first and all middle name(s). Don't include nicknames (which are entered as alternate names).
Use mixed case. Never use all capital letters. 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.
The Surname fieldEnter the surname in full, including multiple parts and articles if they exist (e.g., St. Leger, van der Valk).
Use mixed case. Never use all capital letters. If the surname is unknown, leave the surname blank. Don't include titles, given names, numbers, or placeholder words in the surname field.
GenderUse the dropdown menu to specify gender. Fact typeUse 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 fieldQuick referenceEnter dates as d mmm yyyy. If appropriate, add a modifier (bef, aft, bet/and, from/to, cal, abt, est). Case doesn't matter - WeRelate automatically transforms dates to mixed-case. WeRelate supports dual dating (d Mmm yyyy/yy) - if you are entering dates prior to 1752 and aren't familiar with dual dating, please read Month number and dual dating. Enter proxy dates (e.g., christening date as proxy for birth date, or burial date as proxy for death date) in their own events (not as birth or death date). When a proxy date is used, do not enter a birth or death date that can be derived from the proxy date (e.g., Bef christening date). Source citations should give the date supported by the source in case the date in the date field is changed. If a non-trivial conversion is required, the source citation should include both the date as expressed in the source and the converted date (e.g., 6 (6) 66 [6 Aug 1666]). Further informationDate formatStandard formatWeRelate 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.
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):
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 datesAny date that WeRelate cannot interpret is unacceptable. This includes:
Other dates are also unacceptable, even though WeRelate can interpret them. These include:
Language supportWeRelate 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 abbreviationsWeRelate uses and can interpret standard 3-character month abbreviations, as follows:
Accented characters can be entered without the accent and WeRelate will still understand the abbreviation. ModifiersDates 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. BeforeThe 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. AfterThe 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/andThe 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.
From/toThe 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. CalculatedThe 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". AboutThe 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. EstimatedIn 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 datesLike 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:
Similar conventions apply to other dates that WeRelate doesn't use as proxies:
SourcesAll 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 StyleThe 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 datingIn 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).
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 calendarsThere 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.
Step 3: Search for matches
From the Search page, scan the results to see if a match exists:
How to add a person to an existing treeBuilding 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:
 Example: Add spouse to Family page in edit mode
 Example: Add spouse to Family page directly from Person page From a Person page:
 Example: Opening Family page in edit mode from Person page
Example: Add spouse to Family page in edit mode
How to add a child Example: Add child to Family page directly from Family page From a Family page:
|
|||||||||||||||||||||||||
