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 WeRelate stylistic preference concerning leading zeroes is a subset of the GEDCOM specification. The day of the month should be expressed as 1 or 2 digits with no leading zero. Years 1000 or later should always be expressed with 4 digits ("1753"). Years before 1000 should be expressed with four digits including leading zeroes ("0953"), keeping in mind that events before 0700 are out of scope for WeRelate.
Please use the three-character month abbreviations from the following set: "Jan", "Feb", "Mar", "Apr", "May", Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec". Please use either title case ("Jan"), all upper case ("JAN"), or all lower case ("jan").
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 all upper case, all lower case, or title 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 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 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!]