The latest version of Behold (1.0.1) reports
766: 2 DATE 26 MAY 1935
** Date NonStd (#43): Should be "Sun 26 MAY 1935" to conform to GEDCOM standards.
Is the date with Day part of GEDCOM 5.5.1, as it is not included in 5.5, or at least I cannot see where it is.
Brett: Thanks for this. Yes that is a bug. It should not include the day of the week in the error message. It should simply say:
** Date NonStd (#43): Should be "26 MAY 1935" to conform to GEDCOM standards.
I'll make that fix and squeeze it into a Version 1.0.2 tonight.
Actually, I have to sheepishly say, I had another bug in that all dates that were the 30th of the month were reported as an error as I accidentally omitted "an if month = FEB" from the test. That was mentioned to me about 6 hours after the release, and I snuck that bug fix in a few minutes later, but didn't increment the version as I should have. So I'm coming clean now.
Also, I meant to, but forgot to add an important, but simple change. Currently, a wife's maiden name and all her married names but the last are put into brackets, e.g:
Jane [Smith Jones] White
But I just read that the proper way to do it, according to Mills in Evidence Explained, pages 82-83, is to simply to put only the maiden name into parenthesis, e.g.:
Jan (Smith) Jones White
So I'll make that change as well.
What is your (or rather Behold's) interpetation of the following dates:
Are they valid or invald GEDCOM 5.5.1?
The first four are invalid. You need the year to have a month and you need the year and the month to have the day. Behold will put the first 4 into parentheses, e.g. (13 APR) to make them a date phrase which is valid.
The last two are both valid.
Where sufficient data is not recorded eg only 13 APR, should the GEDCOM be produced containing or excluding the non valid data?
Is it correct under GEDCOM standard to convert non valid dates to a date phrase?
When 1.5 or 2.0 arrives, how do you think Behold will export date phrase to GEDCOM?
It is not correct to put 13 APR into GEDCOM. That is definitely illegal syntax.
There is no "correct" or "not correct" regarding converting non-valid dates to a date phrase. It is my personal opinion that it is best to do so, so that the information entered is still associated with the date and is not lost.
Behold already checks the date and if it can unambiguously figure out what date it is, it will internally convert it to the proper format. If not, it will turn it into a date phrase. So that code is already implemented. There's just nowhere, until version 1.5, to output the result. What you see in the Everything Report is the display format, which is different from the GEDCOM format.
To continue a little, do you consider BetterGEDCOM would be looking at incomplete dates as part of their charter?
It seems to me that where some data is known, eg only day or month but no year, it needs to be kept in the GEDCOM, and within Behold, as you have stated above.
However, if Behold will export to GEDCOM standard, will it not lose the incomplete date data?
Appreciate your effort. See it is a good day there, only -18C.
Over at BetterGEDCOM, they're crossing the entire spectrum of dates, from simple to complex to international, so everything is being looked at.
Personally, I don't think that GEDCOM did that bad a job at defining dates. I like the concept of date phrases for anything that isn't a standard date. A partial date like 13 APR can't be used to figure out ages or ordering, so why try to formalize it?
Behold will export: 2 DATE (13 APR)
That's not lost, and Behold will read it in and display it without the parenthesis as: 13 APR
If it's a date phrase anyway, why not make it look nice and say: 13 April.
Or how about things like: Either 9 April or 13 April or 13 May.
Or: Two weeks before she was married.
I actually had to put the hood up on my coat today. The wind was bad. RootsTech was great: No snow, a lighter jacket and no hat.
Thanks for the clarification on dates.
You must login to post your reply.
Copyright © Louis Kessler
All Rights Reserved