This page is a preliminary draft, a straw man if you will, to help in developing conventions about date usage. Discussion of suggestions and changes should be done on the associated talk page.
General Formatting Rules for Dates
Dates should never be given in numeric form, as there is far too much ambiguity inherent in these forms. If the record of the event uses numeric dates, it should be converted and entered in the form above. (See the discussion of conversion in #Sources, below).
The source for all dates should be cited, so its credibility may be assessed by the WeRelate community (See #Sources).
The day of the month is allowed to be 1 or 2 digits, and the year is allowed to be 3 or 4 digits long according to the GEDCOM specification (). [From personal experience, leading zeros may cause computers to convert the data incorrectly in some circumstances, so I would need Dallan to say if leading zeroes may be used. I would assume they are acceptable, otherwise, as the GEDCOM specification is silent on the use of leading zeros in dates.]
Dates should be made as precise as is known. Often a date is not known precisely, in which case, the appropriate qualifier should be used to indicate what is known, and with what preciseness, as an aid to subsequent researchers. Often, the use of any qualifier may require a note to explain how it was arrived at, unless the imprecise date was taken literally from the cited source. To paraphrase the GEDCOM specification, an imprecise date should not be made to look like it is precise.
GEDCOM does not mandate the case of data, so qualifiers may be upper, lower, or mixed case. Periods should not be used.
Other GEDCOM Qualifiers
Accuracy in Applying Dates
The date field for birth, death and other events should be the dates that the specified event took place. Do not put the dates of proxy events in the place of the actual event. Instead, enter proxy dates as their own fact.
WeRelate's Person Pages always display a Christening fact. Baptisms and christening should be entered in the Christening fact, and not entered as the birth date. If there is no birth date, WeRelate will display the christening date on family pages and search results in its place, automatically. It is not useful to specify the birth as "Bef <the baptism>" when you know and have populated the Christening event.
The birth date should not be estimated if there is no source on which to base such as estimate. Some baptism records record the age of the child at baptism, and a birth may be calculated in this case. But to enter a birth date guessed to be some arbitrary period before the baptism, and assume the same place, may actually mislead other researchers. If all that is known is the baptism, only enter the baptism.
Similar conventions apply to death, burial and wills. Do not assume anything about a burial unless you have evidence of a burial, meaning probably at least the cemetery involved. All people are capable of guessing that a burial occurred shortly after death, probably near the location of the death, so it is not useful to provide those kind of estimates without evidence. Do not use the date of will as the date of death. The date of a will may be useful for constraining the death date when the actual date is unknown, as in "Bet 6 Jun 1779 And 13 Sep 1779", but wills are often written years before death, and it is not uncommon for probate to be delayed several years after death.
Likewise, do not use the marriage bann, or intention, in place of the marriage date. Using "Add event/fact", you may enter a fact type called "Marriage Banns".
Sources should give the date in the literal form found, and if this requires a non-trivial conversion before it may be entered into WeRelate, the converted form enclosed in square brackets, possibly with comments. Non-trivial conversions would include adding information gleaned from context, all-numeric dates, dates expressed using holidays or other descriptive terms (such as Michelmas, or "ult."), calendar shift conversion, or pretty anything more elaborate than rearranging terms or abbreviating the month. For example, 6 (6) 66 [6 Aug 1666] would indicate the source gave the date as "6 (6) 66" which you interpreted as 6 Aug 1666. (This is an example of so-called "Quaker dating" discussed under #Month Number and Double Dating below). This format makes it very clear exactly what information the source supports, and what information came from your conversion of the raw source, so that, if necessary, conversion issues may be discussed.
New Style Versus Old Style
The shift from the Julian calendar to the Gregorian calendar has little impact in everyday lives, but is well within the reach of even casual genealogists. This shift resulted in skipping several days to correct for error in leap year handling. Unfortunately, it was adopted at different times in different countries. In the American colonies, ruled by England, the change took place in 1752, when 2 Sep 1752 was followed by 14 Sep 1752, representing a skip of 11 days. (See ) Complicating matters, the shift should only be 10 days for dates preceding 1700.
Some small number of genealogists believe that all dates should be converted to their modern equivalents to ease calculations spanning the switch-over. However, that leads to ambiguity when looking at a date, and one must analyze each date completely to see which convention was used by that author. Additionally, it is easy to make an error doing this conversion. Therefore, it is simpler and more intuitive to use the default style and rely on genealogical knowledge of the reader to realize that dates before 3 Sep 1752 are old-style and dates after 13 Sep 1752 are new-style.
It is conventional to enter "OS" or "NS" as a suffix when the date is given in a non-default style. However, I believe any such suffix, while preserved, would be ignored by WeRelate software that happens to compare dates. So when contemporaneous sources use styles that were not the default for their time period, it is probably beneficial to convert such dates to their default style, before entering into WeRelate, rather than enter OS or NS. (Make sure to document the conversion. See the comment in the #Sources section about date conversion.)
Month Number and Double Dating
In the United States (and England), a potentially more troublesome issue introduced by the calendar shift was the change of the beginning of the year from 25 Mar to 1 Jan. Prior to 1753, the days from 1 Jan to 24 Mar were considered the end of the previous year. The first month of the year was Mar, and Feb was the 12th month. The example date conversion given in the #Sources section shows the sixth month being converted to August since the date occurred before 1753.
The shift in the beginning of the year causes ambiguity in dates that fall in this period of the year. If one is using the style of date that was contemporaneous, 17 Feb 1717 would occur in the year we now consider 1718. However, if a researcher believes in adjusting dates to their modern equivalent, their use of 17 Feb 1717 would mean a different date. Further, it is common for people that are unfamiliar with this issue to misuse their genealogy software, and end up recording the wrong date. Double-dating is a very simple notational way to indicate exactly to the reader what date is meant and avoid these problems.
If double dating is not used, dates between 1 Jan and 24 Mar, occurring before 1752, will be assumed to belong to the following year, i.e., the assumption is that 17 Feb 1717 is 17 Feb 1717/18.
[TBD: Need help here!]