Help talk:Conventions/Date

estimated marriage dates [21 March 2023]

"estimate marriage dates in order to have multiple marriages display in the correct order in WeRelate"

But a date (or location) is necessary to cause the marriage to listed in the fact list. There is always an info-box even without a date, but since the marriages come after the parents infobox (which may be large if there were many siblings) the infobox for the marriage may not be visible. Thus a casual observer (such as a person searching for a particular individual) may not realize one or more marriages are attached to a person.

For example, today, Person:Matthias Ellis (3) had two marriages, but Family:Matthias Ellis and Mary Burgess (1) had no date and was below his actual marriage Family:Matthias Ellis and Mercy Nye (2), so the infobox was out of the visible area. So even though I had been looking at the page, I did not realize he was attached to this bogus marriage until some other searching returned the family page as a result. --Jrich 20:45, 15 March 2021 (UTC)

The other reason for estimating a date is so that when the family page is listed as a search result, the display is useful enough to at least give an idea of what century it occurred in, so a person working in the 1700s doesn't have to read a bunch of pages from the 1900s because people didn't post either a marriage date or an estimated one. --Jrich 20:52, 15 March 2021 (UTC)

I know exactly what you mean, but I'd like to solve that problem. It's on my list of things to do to display marriages in the event list even if there is no event - I'm just not sure yet how much work that will be. And to be fair, if I see multiple marriages, I try to get or estimate marriage years precisely to get them in the right order even though I could do it manually. But it is problematic when cleaning up someone else's data and you don't even know the order of the marriages. I'll think about how to refine the Help wording (because it is true that you can manually order marriages without estimating dates), but not today.

Thanks for the input.--DataAnalyst 21:02, 15 March 2021 (UTC)

Sorry - I only responded to your first post. I understand your second point as well.--DataAnalyst 21:12, 15 March 2021 (UTC)

Are aliases needed for the qualifiers? [21 March 2023]

It may be desirable to add aliases to the given list of qualifiers, i.e., bef.or by, abt. or calc., est. or ca. --Jrich 12:35, 20 February 2009 (EST)

From Watercooler/Suggestions [21 March 2023]

I attempted to write a guideline for nicer person and family events, but I didn't get far so I never submitted the work for review. Part of that was spent thinking about date formats. The most useful things I came up with were:

Wikipedia has an extensive manual of style, with specific guidance on representing dates of birth and death. Included there is guidance on how to represent approximate dates, date ranges, and more. Werelate adopts this guide with caveats:

If there is a page that already provides WeRelate guidelines, please point me to it. I could not find one using Search on the Help namespace and the WeRelate namespace. The only real comment I found on dates was preferably in the "Day Month Year" format (for example: "9 Aug 1812") which seems a little lacking. If wikipedia's guidelines were enstated (where is this documented?), my comment is that wikipedia's guidelines seem to have some of the same shortcomings that prompted the proposal in the first place.

The motivating problem is frustration over seeing a date given as an unadorned year, which may have one of several meanings:

• that is all that primary sources recorded (and hence all that is likely to ever be known)
• it is within the year somewhere, but too lazy to provide the full precision
• it is calculated to this year (some evidence exists)
• it is estimated (warning: assumptions)

One problem with the wikipedia guidelines is that there is no way to differentiate a calculated date from potentially groundless estimates. While there appears to be one example using "before", I saw no explicit guidelines about using before and after, which is very important in genealogy, as opposed to the obscure "fl." which I don't think I have ever seen in genealogical literature. Wikipedia says to convert dates to the Gregorian calendar which I believe is a mistake because it makes it difficult to compare to sources and it introduces a lot of possible conversion errors. Not to mention those exceptions that you pointed out. So, as stated elsewhere by me, since their purpose is different, it is quite possible different guidelines are needed for WeRelate. --Jrich 17:18, 20 February 2009 (EST)

• absolute genealogical preference for day-before-month forms.
• always abbreviate month names to their three-letter form. Never use a numeric.
• years before 1000 should include a leading 0.
• days of the month before 10 should not include a leading zero.--Jrm03063 13:28, 20 February 2009 (EST)

It's a good summary, but I need two points cleared up: why do we need a period after such terms as bef, aft, est and all the rest? And I've been using btw for between; should it be bet? The other point concerns Quaker dating. I thought it was more than just the year being different. Isn't there a 3 month difference? As when the Quaker records say he was born 12d 2m 1730, I have been using 12d 2m (Apr) 1730. I've always heard we should leave the date as we found it but can indicate a more modern conversion. Maybe I've misunderstood.--Janiejac 13:43, 20 February 2009 (EST)

---

My primary goal is to push people to maximum preciseness, and to differentiate between calculated and estimated dates. I think there are several formats possible for the qualifiers, maybe multiple forms for each, as consensus (or Dallan) finds most suitable, but it more important to me that the meaning of each be clearly understood.

In pondering this since I wrote it, I actually think abt. and ca. have an inherent ambiguity, so at this moment I would have written the page using "Calc" and "Say". "Say" is commonly used in literature to indicate an educated guess and seems to indicate what I mean by Est., and Calc obviously because it clearly indicates there is some reference point from which a date may be calculated, probably indicating somewhat of a higher relibility. I tend to like sentence case and periods because I type reasonably well and it is more like regular English (I hate reading Savage) but have no religious feelings about those attributes. (There is always the issue that Dallan would have to discuss the feasibility and desirability of trying to enforce incoming data, or clean up existing data, to some format, which may well be the make or break point for any convention to work.)

I thought I did write that the date should be given in its original format in the source citation. I proposed a format using square brackets for indicating conversion, i.e., "12d 2m 1730 [12 Apr 1730]", because I think brackets are generally understood to signal editing of the original. For example, your form "12d 2m (Apr) 1730" happens to be exactly the format used in newer editions of the Encyclopedia of American Quaker Genealogy, and it would not be obvious without more information that you interpreted 2m to be April, or the author. (Probably disgressing, I tend to cheat, and if the source uses [], I often change them to () to preserve the use of [] for my comments. If I think that is too dangerous or confusing, then I have to use some more bulky method because it is very important to differentiate between what the source provides and what I interpret.)

Regarding Quaker dating, Apr being the 4th month in modern numbering, isn't that only a 2 month difference to interpret "2m" as April? Before 1752, their month numbering was just the same as everybody else's. What I am not sure about, is whether they continued to use the old style month numbering after 1752, or did different things area by area, or just went along with the civil authorities? [P.S., quick check seems to indicate that they followed civil authorities, not really different than anyone else therefore, except that they tended to use month numbers more than than is seen in civil records, though it is seen there also, so this is not just a Quaker issue.]

--Jrich 14:48, 20 February 2009 (EST)

Is there a reason to not use the ISO standard for dates? http://en.wikipedia.org/wiki/ISO_8601

I'd like to see a discussion of why we don't use it. Or how we decide which standards are chosen?--Jsadler 01:55, 21 February 2009 (EST)

Two quick reasons: 1) this standard's scope is for communicating Gregorian dates, and genealogy must also communicate dates when the Julian calendar was still in use (and before?), and 2) numeric dates are ambiguous (partly because the month numbering changed when the beginning of the year was shifted and partly because the ordering of the numbers must be understood by both the writer and reader of data which is problematical). Also, a minor nit, the form 6 Jan 1898 requires no punctuation to be clear (not even the spaces if you want to push it) and so is difficult to mess up. --Jrich 09:39, 21 February 2009 (EST)

Always more questions, sorry. How would the month names be handled for foreign sources? Keep in native language or translate to current language? Also how about Chinese or Japanese dating systems? (official documents would use the era dating system) Should I/we use dating system in place at the time of the record? This is similar to the Quaker discussion but I believe different in that they are independent systems. --Jsadler 19:34, 21 February 2009 (EST)

I am most definitely unqualified to talk about dates in foreign countries. If you have experience with these perhaps you, or somebody else, would like to add a section. --Jrich 19:47, 21 February 2009 (EST)

Thanks, JRich, for putting this together. I think your proposal makes a lot of sense. I was not aware of the subtle distinction between "abt" and "est" (I had tended to use "abt" for both cases, or just put the year only, which I take as an implied "est"), but will try to follow these good suggestions going forward.

I just had a couple of questions.

One was already asked but not answered: are the periods really necessary for "bef", "aft", "abt", etc.? I have been using those, but without the period. Part of that is just personal aesthetic, but by way of more objective justification, I believe that those tags are used without periods in the GEDCOM standard grammar. Unless Dallan has gone to the trouble of adding periods, I think that anything automatically uploaded from GEDCOM will not have periods after those tags. (They're likely to be in all caps, too.)

On the question of alternate tags ("ca" instead of "abt", "btw" instead of "bet"), since we'd eventually like to be able to generate GEDCOM from WeRelate, I think it's best to stick to the standard GEDCOM tags. Thus, I'd vote for discouraging alternative tags.

The other question is for Dallan. Is there anything being recommended here that interferes with the software interpreting the date for purposes of sorting, matching, etc.? That has been my only hesitation in putting anything other than DD MMM YYYY format in the birth/death date fields. I assumed that "abt", "bef" and others may be safe. The one I particularly worried about was the pre-1752 double year business, you know, "22 Feb 1733/34" for George Washington's birthday. Does the software correctly understand that as "22 Feb 1734" for standard comparison purposes?--TomChatt 04:07, 22 February 2009 (EST)

The date is stored as text so the only issue with WeRelate software is when doing matching and searching where it must interpret it as a date, I believe. I think Dallan mentioned once that he ignored any qualifiers before the date, and uses the first year of double dating. So things like before, after and between get treated the same as the base date. --Jrich 09:49, 22 February 2009 (EST)

Your comment about GEDCOM tickled a nagging concern. GEDCOM is a genealogical standard and is a good place to look for advice, keeping in mind it is designed for computers to exchange information, not necessarily humans. I had inspected the GEDCOM specification before, and expected the date issue to be more prominent, so overlooked some of the detailed specification. Your comment prompted a more thorough inspection. In general, it is not greatly different, but suggests some alteration in my proposal may be good.

The GEDCOM specification does provide ways to give dates in many formats if you use different tags, including things like foreign month names, etc. Unless WeRelate were to add a field where one can identify a date format (like the type of Source), I suspect the date formats must be limited in WeRelate to the default form, which follows the basic double dating form (one of their examples: 15 APR 1699/00).

GEDCOM does support BEF, AFT, BET (though it uses the word AND instead of a dash with BET), FROM and TO (which seems superfluous to me), and INT. (I do not think INT would belong in a WeRelate date field, as interpretation probably should be shown/discussed in a source citation and the date field can simply give the final result. An GEDCOM example is not given, but I suspect Quaker dating might be one place it gets used, e.g., "INT 6 AUG 1666 (6 (6) 1666)", where a GEDCOM is communicating an interpreted date, followed by the non-standard text defining that date. .)

A note about "from/to". The proper usage of "from/to" would be to describe a fact that was true for an extended period of time. For example, "lived in Boston from 1673 to 1690". "Bet/and", on the other hand is for a discrete event that took place between two dates, e.g., "born between 1670 and 1680". I did not take the liberty of updating the Help, where it advises against using "from/to" - but if you see my point, you may want to do so.--DataAnalyst 20:31, 4 January 2011 (EST)

I see your point, though though I think it is largely a grammatical difference in a data representation environment. However, a valid point, and I will try to adjust the comments. Feel free to do more if I don't do it justice. --Jrich 22:25, 4 January 2011 (EST)

The GEDCOM specification supports three qualifiers, ABT, CAL and EST. The first is for an inexact date. This would presumably be when the primary source is incomplete, worn or torn? CAL is for a calculated date, and EST is for a date approximated based on another event. Being unaware of CAL, my proposal was using ABT for CAL, since I thought use of an incomplete date implied ABT, but it is probably better to adopt the GEDCOM system here.

Regarding periods and capitalization, GEDCOM does not seem to mandate upper case within data though all examples shown are upper case, and it does not use periods after these tags. For the reader of WeRelate, I suspect there is not much difference seeing After, AFT, aft, Aft., etc., on a WeRelate page. This issue would be more of a specification provided by Dallan based on how much flexibility he thinks is reasonable without losing the ability to convert WeRelate data into a GEDCOM. --Jrich 10:58, 22 February 2009 (EST)

We should kick-start this again... [21 March 2023]

We should get this actively moving again. We're eventually going to want to have data sanity routines work through the WR data base, and those are going to rely heavily on the ability to recognize dates. Indeed, the first such one I would suggest would simply walk through looking for bad dates. A couple of on-point notes:

• I skimmed the document and the suggested/recommended prefixes for estimated, before, between, etc., appear in all upper case, though a case preference is disavowed. For GEDCOM purposes, perhaps case doesn't matter, and - for purposes of import and export such strings should just be left alone. However, when they appear displayed on a page, all capitals is a screen real estate hog, besides distracting from the date proper. For that reason, in my work, the only thing (in a date) that I capitalize, is the first letter of the month abbreviation. So I would turn "BEF 20 FEB 1690" into "bef. 20 Feb 1690". Likewise "BET 11 JAN 1490 AND 6 JUN 1491" would be "bet. 11 Jan 1490 and 6 Jun 1491".

• Maybe I didn't look closely enough, but we probably also need to deal with "Old System" dates. I worked through a bunch of Imperial Russian stuff and there are a lot of dates noted "O.S." and similar. If the source records a date in OS, then it's probably improper to compute the NS date and write that as documented by the source (A cute behavior: I'll bet that WR page display code could be made smart enough to recognize "OS" dates and then automatically provide an NS corrected value for purposes of display).

• Also from the "getting cute" department. It's often the case that we have a DOD and "ae" description. If we could standardize the "ae" portion somehow/somewhere (presumably in the DOD description string), then the page display code could automatically roll up an estimated DOB (less hazardous and more faithful to sources, since it really isn't a permanent part of the record for a person).

--Jrm03063 09:06, 28 October 2009 (EDT)

I am fairly sympathetic with your comments. However, WeRelate does very little processing of the dates, which is probably not unreasonable, allowing almost anything to be input, leaving it to the users to clean it up. Building knowledge of dates into WeRelate raises the possibility that it will cause problems with unanticipated input, so implies continual vigilance and the possibility of frustration by some future user. Dallan has explained his date processing somewhere, and it is fairly rudimentary, seemingly in keeping with this minimalist philosophy. For example, children born "aft. 4 Jul 1776" will sort before "bef. 4 Jul 1776". So these suggestions (understanding O.S., ae/Aet, etc.) represent quite a couple of quantum leaps in capability. --Jrich 11:11, 28 October 2009 (EDT)

Well, I'm not sure if it's all that much of a quantum jump. Still, I think it's a good data base sanity step to start walking through the data base, looking for dates that can't be understood in a compute sense. To begin with, all that we would probably do with that is to issue a per-page warning about an unrecognizable date string attached to some fact. Doing that though, means that we decide two things: what date syntax is recognizable and then, what date syntax is preferred (presumable the latter is a subset of the former).

I think this document is a good start on the latter. I know how to write parsers that can do the former, though I've never had a reason to work in PHP, or write code that lives on a web site or as an agent, etc. If Dallan could specify a framework for operation, maybe I could write some code that would do this. Hmmm... --Jrm03063 11:47, 28 October 2009 (EDT)

Oh, BTW, my thinking here isn't that this precludes users from entering anything - either via GEDCOM or normal page editing. I see this as a detached process that walks around and looks at person/family page fact date strings. When it finds a page that has unrecognized date strings, it either adds the name to a list of "date troubled" pages, or adds a warning to the associated talk page. Probably the former at present. Maybe the correct model is actually like a spell checker - build up a unique list of date string forms, attached to the pages that contain that string. Then walk the list and build up a second list of date-troubled pages accordingly. Or something like that... --Jrm03063 11:54, 28 October 2009 (EDT)

Date Parser? [21 March 2023]

It's been a while since I was a compiler writter, but I'm sure I could roll up some code to actually implement a date string parser/validator. Are we about there?

--Jrm03063 11:18, 5 January 2011 (EST)

Standardizing Dates? [21 March 2023]

We are approaching a time when we'll be able to have bots that work their way around and perform minor edits such as normalization of date string forms. There was recently some discussion on this on the WaterCooler. I think it makes sense to have a WR preferred form that's a little more narrow than GEDCOM. I really like mixed case for a month specifier, but all lower case for any other non-numeric. I can go either way on whether some of the abbreviations should have a trailing "." - which does not appear to be GEDCOM standard - but we probably should articulate a preference. --jrm03063 11:48, 12 November 2012 (EST)

My personal preference is to like mixed case in the qualifier too, because the fact on a page looks like sort of a sentence, and it starts with the date qualifier, and so it looks odd to see it start with a lower case letter. My second choice would be all caps because the presence of the qualifier tends to get ignored by careless researchers that don't realize what a big difference in meaning it makes. But those are personal preferences, and fundamentally, all cases communicate the date. I would like to see this suggestion implemented where Dallan forces all dates into whatever form he likes and this issue stops wasting time when it really makes no difference to the meaning of the data. --Jrich 13:56, 12 November 2012 (EST)

I just went to Help page for Date Conventions to read what was there. I do not understand why all the qualifiers are in ALL CAPS and the resulting date(s) are in mixed case. Even that mixed case does not look good to me as I would prefer the words to be all small case. Example:

"The qualifier "BET ... AND" may be used to indicate a range of dates, where known dates define a window within which the 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." Now why in the world should Bet & And be capitalized? --janiejac 14:40, 12 November 2012 (EST)

As the author of that page (long ago), I can answer that. The page was written looking at the GEDCOM specification. The GEDCOM specification doesn't care, in fact, states that all the various case arrangements should be accepted and treated as the same value. That basically means all the cases being talked about in this discussion are legal, and none are wrong. In the text of the Help page, the qualifiers were capitalized to make them stand out as keywords, meaning those exact three characters were required. This is, I believe, a common convention in computer manuals. I believe, though it is a very old Help page and I haven't read it in a while, that it does state explicitly, that any case is legal. In the example they were mixed case because that is my preference (see explanation in previous post), and as that was how I normally entered them on pages, I entered the examples like that. As it is not wrong, it is by definition, legal. It is purely a matter of personal preferences and likes that are being discussed here. Meaning there is no right answer. Meaning the answer to "why in the world" is because somebody likes it and it is not illegal.

Many software programs (like Family Tree Maker) do make the months and qualifiers upper case, which means anybody loading data from one of those programs is going to have their data end up in that form regardless of what any conventions say. Personally I think it is a waste of time for people to be busy changing these dates when the next GEDCOM touching that page is very likely to make it upper case again. This is a losing battle. So if a particular form is desirable, then I think the computer should enforce it. That would make this whole issue moot. Personally I think Dallan should choose one that strikes him as functional and aesthetically pleasing, that simplifies the import and export of GEDCOMs, and that allows for him to sort and compare dates efficiently. People could import, or enter, dates in whatever form they like and the computer should force them all into the selected form, or turn them red if it can't figure out what they mean. After all, whether Dallan chooses ABT, Abt, abt, or even circa, I think we'll all understand what it is saying. --Jrich 16:40, 12 November 2012 (EST)

I would think that we'll have no trouble creating a date parser that will read everything that GEDCOM allows and probably a good deal that it doesn't. What this group can best add is what subset of the GEDCOM format looks best when it appears on a resulting page. Also - whether that exact form should be used in exported GEDCOMs - or something slightly different. Lets just take it as a given that any date form normalization would be done by software - so no one will be going back and changing "ABT" to "Abt." or "JANUARY" to "Jan" or whatever. --jrm03063 19:01, 12 November 2012 (EST)

if you're exporting via GEDCOM, you won't be doing something "slightly different". That means ABT, in some case, but no period, for example. If Dallan wants to build the software to convert from, say "Circa" to ABT, that's fine, but it will go out as ABT (in some case combination) if it is GEDCOM. Otherwise, it's not GEDCOM. The only leeway here is how to display it while it's in WeRelate. --Jrich 22:23, 12 November 2012 (EST)

By slightly different, I mean different within the set of forms that are legal GEDCOM. In other words, for display we might prefer that some strings are mixed case or lower case - while folks might prefer that things are upper case for export - but I thought that was obvious. --jrm03063 22:29, 12 November 2012 (EST)

If you are going to have the software normalize the capitalization, I won't say much about it here since I am indifferent what convention you choose. But I do believe that the punctuation should be left out. It appears odd to me to see “Abt. Nov 2012” where there is mixed punctuation. I would prefer to just see it as “Abt Nov 2012”. —Moverton 00:27, 13 November 2012 (EST)

Date format standard for Quaker dates after 1752 [21 March 2023]

I recently discovered that some (but not all) Quaker communities continued to number months after 1752 as they had prior to then (i.e., 1 = March). This appears to be contrary to the direction set by the Friends in London - extract from a Minute of The Meeting for Sufferings in London, dated the sixth day of the Seventh Month, 1751.

According to this write-up on Quaker Dates, the best advice is that, unless you have evidence of which style of dating is being used, you should copy the date exactly as written and not convert to alphabetic months. Note in particular the example at the end of the document, which provides evidence (assuming no transcription errors) that Old Style dating was in use in Queensbury as late as 1809.

I would ask that someone else review this material and determine whether and how to change the WeRelate guideline. I didn't want to do it unilaterally, although I have been following the advice given in the PDF.--DataAnalyst 22:21, 25 August 2013 (EDT)

If you find some evidence that some community persisted in old style dating, then that is evidence that you should probably provide along with any date from that community (a template attached to all source citations for that community, one assumes). But that is not the general case. All date handling is somewhat unreliable, as the scribes were obviously influenced by practices in different countries, or changes they knew were coming, and certainly the changeover did not strictly follow the effective date of the various laws. Often a second source is required to explain why one interpretation or the other was necessary. But, in my personal experience, I don't recall a single example (when able to compare numeric dates versus named months, either due to there being both civil and religious records, or when the clerks added comments giving both forms), that Quakers did anything other than use the legal numeric forms of the date. So, before 1752, month 1 = March, and after 1752, month 1 = January unless I have other evidence. In any event, I always try to preserve the original form of the record in my source citation, but not in the fact, since the fact represents what I think the best answer is, and is given in WeRelate conventional form. The source citation is the place where the form that the source uses should be given and analyzed, while the fact should represent the final answer, since there are often multiple sources, using different formats, that contribute to what I think the best answer is. --Jrich 23:17, 25 August 2013 (EDT)

Thanks for responding so quickly. I guess I was overly influenced by the article I read, not having had previous exposure to Quaker records (I am uploading someone else's data for them to continue refining on WeRelate). I just started uploading a large file, so I appreciate being given the heads-up early on. --DataAnalyst 20:19, 26 August 2013 (EDT)

Calculated dates [21 March 2023]

Having written the original page, the intention of calculated was to attempt to distinguish between dates that are estimated and dates that have some basis. However, it seem potentially misleading to say "cal 1614" when age at death could equally result from a birth in another year. For example a death 25 Oct 1682, age 68, could result in any date from 26 Oct 1613 (one day before he turns 69) to 25 Oct 1614 (his 68th birthday). This hardly seems like a calculated date. This is, unfortunately, the type of example I put on the Help page. I believe it should be changed.

It seems like the cal qualifier should only be used when the precision of the duration is to a specific number of days, since only then does the date really get calculated. Otherwise it is estimated only to the precision of the duration. A standard rule of science is that you can only measure things to half the precision of the instrument. Thus, a duration expressed in months can only be assumed to be plus or minus 15 days. Thus, with any lesser precision than days, the calculation rarely results in a date that you can guarantee to be in the same month or same year. It seems like abt expresses the precision of those dates better than cal. --Jrich 03:12, 5 June 2016 (UTC)

Leading zeros in years - can we change the convention? [21 March 2023]

I would like to question the convention for leading zeros in years before 1000. This came into WeRelate in 2009, seemingly without discussion, and supposedly as a Wikipedia standard. Whether or not this was a Wikipedia standard in 2009, it is not today (see the article on Charlemagne, or any other person from before 1000).

One of the things we struggle with is making WeRelate attractive for new users and to retain users. Using leading zeros does not make the site attractive - it appears too computer-technical.

Before we automate date formatting (which is under discussion, and I believe feasible to do soon) can we align on removing leading zeros from years before 1000?

BTW: I have tested search on these years, and there is a bug regardless of whether or not there is a leading zero - worse if there is no leading zero. But I have asked for the bug to be fixed (see WeRelate:Suggestions/Search for dates before 1000 (current functionality is incomplete)). Other than this bug, I can see no advantage to having leading zeros.--DataAnalyst 17:06, 22 December 2016 (UTC)

I don't understand why you are concerned with the first millenium dates. I thought the policy of WeRelate was to not mess with people from early history since hardly anyone would ever be able to take their genealogy back that far with anything more reliable than pure speculation. -Moverton 20:50, 22 December 2016 (UTC)

WeRelate policy allows for genealogy back to 700.--DataAnalyst 20:59, 22 December 2016 (UTC)

I have commented on leading zeros elsewhere, but I will repeat here as well to make sure my vote gets logged. I do not think that our conventions should include a requirement either for or against leading zeros in days or years, since GEDCOM 5.5.1 does not address leading zeros, and their presence or absence does not appear to have an effect on searching and sorting capabilities within our program. Based on this, I would also ask that any program written to correct unacceptable DATE_VALUE formats be written to define both those with and without leading zeros as acceptable. --cos1776 21:28, 24 January 2017 (UTC)

Capitalizing qualifiers [21 March 2023]

Another convention to align on is the capitalization of qualifiers. I think most people agree that all caps is ugly, but there seems to be some disagreement on leading capitalization.

I would argue for all lower case, as this is not the beginning of a sentence. Those of using desktop genealogical software may be used to seeing qualifiers in all lower case so that they fit into sentences generated by the software (e.g., George Smith was born abt 1583 ...)

Also, if you look at a family page where some of the children have christening dates instead of birth dates while others have estimated or approx. birth years (e.g., Rasmus Christensson Møiland and Marie Tolvsdatter), it appears more consistent if the qualifiers are all lower case.

Does anyone object if I update the convention to indicate that all qualifiers are in lower case? (We'll seek automated conversion to lower case from GEDCOM files sometime in the future, and live with the ugly all caps in the meantime.)--DataAnalyst 17:24, 22 December 2016 (UTC)

This is an area where I think software is the answer and it is pointless to do anything until the software is written. After all, all somebody has to do is upload a Gedcom and it's probably going to be wrong again. The software should format the data on save, and whatever format it chooses will obviously be the convention. This would avoid pointless edits just to change the case, which changes the meaning and quality of the fact not one iota... I assume every reader can process the date regardless of how it is capitalized so this really doesn't impeded the communication of information. It is largely a matter of personal preference.

I disagree with the "this is not the beginning of a sentence". While it is not prose, it is the answer to a prompt, and acts like a sentence giving the reply to a question, so should start with a capital. In addition, since most of the other fields are proper names, it looks out of place to my eye to have this one start with a lower case letter.

Functionally I like starting with a capital because I think attention needs to be called to the qualifier. Anytime something is entered in a date that is not an actual date, the qualifier is a critical item. Too many sloppy websites take dates like bef 1690, or abt 1690 and just present them as 1690, when they have very different meanings. --Jrich 19:36, 22 December 2016 (UTC)

I can buy the argument about making the qualifier more noticeable by capitalizing it. Anyone else have an opinion one way or the other?--DataAnalyst 20:01, 22 December 2016 (UTC)

To be consistent and not have to spend much time thinking about it, I just capitalize the first letter of each word (eg. "From Jan 1690 To Sep 1699"). Capitalizing the user-entered info does separate them from the system defined indicators like "chr." and "bur.", which can be good. I never make edits for the sole purpose of correcting capitalization. I just do it when I happen to be doing other work. -Moverton 20:44, 22 December 2016 (UTC)

Just my personal opinion, but I dislike all caps such as BEF, ABT, EST, BTW. I know my GEDCOM uploads post this way, but I change it to all lower case whenever I'm on a page using all caps. And remembering what should be capitalized and what should be lower case (Bef, Abt and Est) may be more work than necessary. Looks like a variety of opinions! --janiejac 01:27, 24 December 2016 (UTC)

Also prefer all lower case -- more aesthetic, more consistent with ca for circa (which is where I started--GayelKnott 00:00, 24 January 2017 (UTC)

As I read things, circa, ca, is not technically a legal qualifier according to the GEDCOM Standard. Therefore its use would properly require support built in to the GEDCOM export process to convert it to abt or est if WeRelate is to generate legal GEDCOMS. --Jrich 01:02, 24 January 2017 (UTC)

Since casing style specs vary from genealogy program to genealogy program, most GEDCOM readers, validators and writers are intentionally written to be case insensitive. I think we should follow their lead. We do not need to regulate casing style for legal qualifiers. It is a subjective preference and has no effect on database efficacy. Punctuation is different, however. The only DATE_VALUE punctuation given in an example in GEDCOM 5.5.1 is "/" used in double dating ("15 APR 1699/00"). There are no periods after qualifiers or dashes between dates to indicate period or range. --cos1776 21:28, 24 January 2017 (UTC)