ViewsWatchers |
Revision as of 15:03, 11 September 2022
Quick 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 standard mixed-case format. WeRelate supports dual dating - if you are entering dates prior to 1752 and aren't familiar with dual dating (d Mmm yyyy/yy), 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. Years before 1000 don't have leading zeroes.
Dates may include text within parentheses, either as the sole contents of the date field, or after the date. WeRelate preserves this text but ignores it when it comes to 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 and Spanish as of March 2021). These will be 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 will be 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" may be used to indicate that an event occurred on or before the indicated date. For example, a will dated 15 Jun 1863 may refer to a deceased neighbor, so the death date of the neighbor would be specified as Bef 15 Jun 1863. AfterThe modifier "Aft" may be used to indicate that an event occurred on or after the indicated date. For example, if a person acknowledged a deed on 22 Apr 1704, their death date would be Aft 22 Apr 1704. Between/andThe modifier pair "Bet ... and ..." may be used to indicate that two known dates define a window within which an event occurred. For example, if a person's will was dated 10 Nov 1798, and proven 20 Nov 1798, the death date would be specified Bet 10 Nov 1798 and 20 Nov 1798.
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 a discrete 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" should be used when a date has been calculated by adding or subtracting an exact number of years, months and days from a precise date. The use of "Cal" informs the reader that the date was derived and not found in a source. This is important because the information used for the calculation (e.g., age at death) might not be correct (even when expressed with year/month/day precision), and because the person doing the calculation might not know which convention the source used to determine the number of days between two dates (e.g., inclusive of both dates vs. exclusive of the starting date). By using the 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 known date and a known time span (precise to the number of days) to use in calculating a date, and not when the date is estimated based only on a known date or an imprecise time span. For example, since people get married at different ages, any birth date derived from the marriage date must be estimated, not calculated. If an age is given but is expressed only in years, it is more appropriate to use the modifier "Abt" (see below). AboutThe modifier "Abt" should be used when a year (or, occasionally, a year and month) is calculated from a known date and time span where either the known date or the time span (or both) are not precise to the day. The most common example of this is when the birth year is derived from an age expressed in years. "Abt" is used because it is possible for the person to have been born in the year calculated as "known year - age" or in the previous year. Another example would be a marriage year derived from the number of years married. Occasionally, a source is imprecise, and "Abt" is the only way to express this. For example, in colonial times, when families would move to a new town, the father would often provide birth dates for his children to the town clerk, even though they were born before the move. If the father's memory was faulty, these records sometimes read "born about the 15 of June 1684" or similar. To communicate as precisely as possible, other 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 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 datesThe date field for birth, death or other event should be the date that the specified event took place. Do not put the date of a proxy event in place of the actual event. Instead, enter a proxy date as its own fact. Like many genealogy applications, WeRelate treats christening date as a proxy for birth date when only the christening date is known, and burial date as a proxy for death date when only the burial date is known. Therefore, if only the christening date is known, nothing should be entered into the birth date field (neither the christening date nor a guess based on an arbitrary number of days before the christening, which could mislead other researchers). Similarly, if only the burial date is known, nothing should be entered into the death date field.
When a christening or burial date is used as a proxy, do not enter a birth or death date that can be derived from the proxy (e.g., Bef christening date). Also, to avoid misleading other researchers, do not assume that a person was born where they were baptized, or died where they were buried. Entering anything into the birth or death date or place field will prevent WeRelate from using the christening or burial date as a proxy on display screens, giving other researchers less information than an exact christening or burial date. Note that in addition to the christening date, WeRelate also has a baptism fact (using "Add event/fact"). For groups of people that practice adult baptism (e.g., Baptists, Mennonites), the baptism fact should be used instead of the christening fact. As well, when it is clear from a record that a person was baptized as an adult (or even as an older child), the baptism fact should be used instead of the christening field.
Likewise, do not use the marriage bann, or intention, in place of the marriage date. Using "Add event/fact", you may enter a fact type called "Marriage Banns". 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. Note: 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. 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. |