Out on a Bad Date - Wed, 14 Dec 2011

It seems that I’ve created a series of posts about dating. First there was Sort of a Date where I discussed the problems in sorting GEDCOM dates. Then there was How About a Date? where I reviewed the GEDCOM syntax for dates and how many programs break them.

While writing my FixDate function to correct those illegal date functions, I realized that GEDCOM was asking that you enter only dates that actually exist, but there was nothing in the GEDCOM syntax itself that specifically defined what dates these were.

Well, genealogy programs should be smart, shouldn’t they? If they’re helping you to enter dates from long ago, wouldn’t you want your program to check your date for you and tell you right away if you’ve got something wrong.  I would hope you wouldn’t be able to enter “36 Feb 1938” as a date – but to my shock, I found that in a Brother’s Keeper GEDCOM.

I was curious to see how bad the problem was, so I decided I’d try searching for a few non-existent dates on Google using filetype:ged in the search to only give GEDCOM files in the results.

My first thought was that programs might not check for leap years correctly, so I searched:

• 29 FEB 1897 – 1 result, MyHeritage
• 29 FEB 1903 – 2 results, Family Origins and PAF
• 29 FEB 1906 – 1 result, PAF
• 29 FEB 1909 – 1 result, Ancestry.com Family Trees
• 29 FEB 1910 – 1 result, PAF
• 29 FEB 1911 – 2 results, Family Origins and PAF

So … there appear to be at least a few programs that don’t check the leap year for you.

Then I tried:

• DATE 30 FEB – 24 results, Brother’s Keeper (3), PAF (11), Family Origins (3), RootsMagic, Legacy (4), BasGen and one stated to be from: AAAAAA (Eh what?)

Well what about:

• DATE 31 FEB – 14 results, plus Family Treasures, Heredis and Pro-Gen 2
• DATE 31 APR – 40 results, plus EFTree and Holger (which doesn’t exist)
• DATE 31 SEP – 32 results, plus GenoPro
• DATE 31 NOV – 37 results, plus Ancestral File and CFTree
• DATE 32 – 1 result, EasyTree that gave 32 Dec 1841

Granted that many of the GEDCOMs on the web are quite old and produced by earlier versions of the above programs. But this is a basic check all genealogy software should do for you. If your program is mentioned above, then it is possible it still allows non-existent dates to be entered into it.

I just tried entering 29 Feb 1943 into RootsMagic 4 not using its little popup calendar (since the calendar does not have that date on it). RootsMagic highlighted the date in light yellow in a passive way to signal a problem, but accepted it. So then I tried adding 43 freb 1943 (yes, with FEB spelled as “freb”) and it accepted that as well. I exported the file, and the GEDCOM line said:
     2 DATE 43 freb 1943
That is not good. RootsMagic knows it’s a bad date. Exporting it that way is illegal in GEDCOM and will create problems when other programs read it. At the minimum, this date should have been converted to a date phrase for export by enclosing it in parenthesis, which is valid, i.e.:
     2 DATE (43 freb 1943)

Try entering some of these illegal dates in the program you use and see what your program does with them.

Still curious, I thought I’d try a more difficult date construct. There are the double dates caused by the change of calendars in 1583. This is something that’s tricky even for genealogists to get right. Basically the years from 1583 to 1751 could be written 1583/84 to 1751/52, but only from January 1st through March 24th since one calendar had January 1st as the start of the new year, and the other had March 25th as the start. From March 25th, the year is the same and a double date should not be used.

You’d think if a program allowed you to enter double dates, they’d at least help you by letting you know you didn’t get it right.

I tried searching for some illegal double dates and found these:

• DATE 1579/80 – 1 result, FamilyOrigins
• DATE 1577/79 – 1 result, Brother’s Keeper
• DATE 1575/76 – 1 result, FamilyOrigins
• JUN 1719/20 – 1 result. Brother’s Keeper. Invalid.
• NOV 1719/20 – 1 result. Brother’s Keeper. Invalid.

Hopefully these programs are not improperly using the slash as an “or”, because that is also illegal GEDCOM.

RootsMagic 4 in its help file says it does support double dates, and does put in checks for you. That’s good and you want that. Unfortunately, they may export their double dates as 1698/9 instead of 1698/99 and as 1699/1700 instead of 1699/00 as GEDCOM specifies. Because of that, programs inputting GEDCOMs from RootsMagic 4 may not be able to read those double dates correctly.

It is not difficult to do basic checks that a date exists. I’m currently just about finished including checks in Behold and adding “illegal date” as a new **data error** message so that Behold will help you identify any known-to-be illegal dates that you might have in your data. This should be in the almost-ready Version 1.0.1 of Behold. And when editing is added in Version 2.0, Behold will let you know if you try to enter an illegal date and will give you the chance there and then to correct it.

But the sad thought I have about all this is: If genealogy software vendors can’t even do a simple date check in their programs, and can’t even output their date field to properly follow the GEDCOM standard for it, then that really worries me. These programs seem out to do their own things their own way, and don’t seem willing to cooperate in the way they do things with anyone else or follow the established standards. Unless this attitude changes, there will be no hope of improving data transfer between programs and initiatives such as BetterGEDCOM will be doomed to fail.