Family Historian User Group

When I open my gedcom file in GEDExplorer I get a warning about a non-standard date as shown.


Does anyone have any ideas on how I can determine where this error is? At first I thought maybe it was a line number, but I don't have that many lines in my gedcom. I ran a validate in FH and it shows no errors.

Any help appreciated.

Thanks,
Bill

I wonder if the Position is a character or byte count, and maybe the Non-standard DATE is a Date Phrase?
Despite being valid GEDCOM maybe GEDexplorer does not think so!

You can review all Fact Dates by using the View > Standard Queries > All Facts and sort on the Fact date column.
After all the blank dates, any Date Phrases will be listed 1st enclosed in "double quotes" before all normal dates.

Mike,

Good idea, but I don't have any date phrases in my file. Oh well... isn't causing any major problems or anything. Just an irritant to see that warning every time I start it up.

Thanks,
Bill

Bill

Have you tried contacting the developer? They quote an email address of software@sundin.nu

Russell,

Thanks for the reply.

I had sent them an email, but haven't heard anything back.

Bill

I think it's a character position. If you open in an editor like PSPAD there is a go to by character.

This is a perfect example of the worst type of 'anonymous' error message.
The Position number is useless unless its meaning is described somewhere.
The Non-standard DATE message is useless without showing the actual DATE text.
Is there any Help that explains either of the above?
May I suggest you Email the vendor with that feedback.

Regarding PSPAD, the go to character position option is a little hidden.
Use the Search > Goto Line... command where the Abs.position: specifies a character (code point) position.
But remember that in a UTF-16 LE Unicode encoded GEDCOM file that is half the byte position count.

tatewise wrote: ↑

23 Aug 2020 10:17

Use the Search > Goto Line... command where the Abs.position: specifies a character (code point) position.
But remember that in a UTF-16 LE Unicode encoded GEDCOM file that is half the byte position count.

This is all Greek to me. Does this mean I have to divide the number in the warning in half and use that in the Abs.position: field?

Bill

I downloaded and installed PSPad.

I did the search using 5,886,306 which is half the number in the warning. There was a date at that approximate position... 12 Feb 1733/34.

This seems to me to be valid, so I looked in my gedcom to see if I had other "double dates". I do. None of them were flagged in the warnings.

So I changed the date in the warning to not be a "double date". I loaded the new gedcom in GEDExplorer and now the original location was not flagged, but it flagged a different location. That also had a "double date".

So it appears that GEDExplorer does not accept these "double dates". It also appears to only report the first warning it finds so any other warnings are hidden until you fix the first one.

I'll report this to the author, but I guess based on how I use the app I'm not that worried about it.

Thanks Jane and Mike for your help.

Bill

Bill, you seem to have worked out the solution OK.
It is quite common for genealogy products to mishandle double-dates.

I presume you realise that UTF-16 Unicode holds every character as two bytes, i.e 16 bits.
Whether you need to divide the Position in two depends on whether GEDexplorer counts in characters or bytes and it does not say which. It seems it counts in bytes because dividing by two gave a sensible PSPad character count.

I finally heard back from Christer Sundin at GEDExplorer. He indicated that

GEDexplorer doesn't support the use of "/" in dates so that is something I need to improve.

Bill

Lack of support for double dates is a major omission of a standard GEDCOM Date format.
Hopefully, he will improve that soon.

I hope you also complained about the abysmal error report that doesn't show the problem line of text nor give a line number, and only lists one problem at a time.

Mike,

I did mention that it would be nice to see the line in error and have a line number rather than byte location. I forgot to mention the one error at a time issue.

Bill