The automatic conversion that you get when you edit a date works, because when you edit a date, Gramps uses your language and display settings to interpret the date in the right way. This means for example, that when you have settings to display month names, that the GEDCOM importer will not understand MAI, because it’s not MAY, but the user interface will understand it, just like it understands MEI here.
The same is true when you type 10.9.1941, because Gramps knows what it means in a German context.
It could be, but it’s not true. I have a tree on Ancestry.com, and all dates are exported in the proper GEDCOM format, even though they have long month names like March on site. And when I want, I can also use RootsMagic to download my tree, thanks to the fact that they have a license to use the Ancestry API. I often use this when I added some media on-line, because RootsMagic can download media too. And it does speak better GEDCOM too.
I must add that the reply that they sent to Walter is wrong, because my latest export from the site is definitely GEDCOM 5.5.1.
While the 7.0.11 specification was published 1 November 2022 (a 7.0.12 update has been published since then), that is irrelevant to the date format being wrong. Regardless of the version being 5.5.x or 7.x.x, the standard still calls for dates to be in the ‘d MMM yyyy’ format by default.
Full disclosure: Gramps has NOT implemented a plugin supporting the version 7 GEDCOM specification. We still use the version that has been the de facto standard for more than 20 years: GEDCOM 5.5.1
I have not seen an announcement that Ancestry has exclusively switched to GEDCOM7 either. Can someone point us to that announcement?
Thank you. Since i am not a paying subscriber to Ancestry, they aren’t likely to answer my questions.
Could you ask them for a link to a support document stating when they started exporting GEDCOM7 format and had discontined the 5.5.1 support for export?
That’s not a passive-agressive question. I just want to put it in the timeline for our wikipage on working with GEDCOM from different software.
“Unfortunately, you need the current version 7.0.11, which was released on November 1, 2022. GEDCOM 5.5.1 is already very old. It will not be possible to generate older versions.”
This was translated by ChatGPT, and it’s not true. I just asked Ancestry.de to generate a new GEDCOM for download, and its header looks like this:
0 HEAD
1 SUBM @SUBM1@
1 SOUR Ancestry.com Family Trees
2 NAME Ancestry.com Member Trees
2 VERS 2022.08
2 _TREE borg
3 RIN 189696468
3 NOTE My main database
3 _ENV prd
2 CORP Ancestry.com
3 PHON 801-705-7000
3 WWW www.ancestry.com
3 ADDR 1300 West Traverse Parkway
4 CONT Lehi, UT 84043
4 CONT USA
1 DATE 2 May 2023
2 TIME 15:11:03
1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
And as far as I’m concerned, pushing version 7 would be quite foolish, because the big players, at least the ones that I know, like Ancestral Quest, Legacy, and RootsMagic, don’t support it.
I agree that it would be premature. But it might be a viable marketing feint. They could claim to be supporting the “latest and greatest” while effectively removing the ability to switch to a competitor and to put down competitors as “using obsolete technology”.
So, given their history of predatory marketing policies, I did not dismiss the possibility.
Yes, told you so. I knew about Family Historian, and it is quite interesting to see that list of German developers that support it already. They’re all small players though, I think.
Yes, everyone is agreed the GEDCOM7 was a bit of misdirection. We’re beating a dead horse again.
The REAL issue remains the “d.m.yyyy” dates being the wrong format for conformance with EITHER version.
Maybe we could try to document a hack for the GEDCOM import plugin to make a dialect importer version that expects & parses “d.m.yyyy” format dates? Then people would have a pattern to tweak that code for their particular GEDCOM date ugliness. (The GED2 addon is only an Export plugin.)
That’s right, but the issue itself is quite complex, because in this case, the d.m.yyyy format looks perfectly OK for a German user, just like dd-mm-yyyy is for me. And a quick test on Ancestry suggests that the site gives no warning about ‘wrong’ dates by displaying those in bold, like Gramps does, so that many users may not have any idea about anything being as wrong as we think it is.
When I look at my own tree on Ancestry, on their American and German site, I see many dates showing the GEDCOM format exported by Gramps, with 3 letter month names in upper case. Some dates show long month names like March, for which I would expect the German site to show März, which is doesn’t do. And that makes me think that Ancestry’s date handling is quite sloppy.
When I try to enter dates on-line, using the Dutch dd-mm-yyyy format, or the German dd.mm.yyyy, Ancestry does give me a warning, both on the American and German site, but I have no idea whether you will also see that in the Android app, or whether this has always been the case. And even if the site does give a warning, a user may still prefer his local format, especially if he’s not aware of the consequences. And I bet that Ancestry does not give these warnings when you import a GEDCOM file, so these ‘wrong’ dates can survive very long without ever getting noticed. The fact that I’m aware of this is likely caused by my experience with PAF, which taught me a lot about proper dates.
And yes, it would be nice if we could improve support for this by looking for common patterns on import, like the Dutch dd-mm-yyyy and the German dd.mm.yyyy, and remove the automatic conversion that assumes that dates with numbers only are American.
On the subject of date format. I found 2 identical source records today, one on Ancestry and the other on FMP. One showed 9 MAR 1938 and the other site 3 SEP 1938. There was no images to view to see which one was correct.
The only formats I support are YYYY-MM-DD or DD-MMM-YYYY. In GRAMPS I use YYYY-MM-DD. In Ancestry and FMP I use DD-MMM-YYYY as it seems to be the most popular, however you can enter anything in the date field and it will be saved.
That’s right, and that’s a problem if you don’t realize what’s going on behind the scenes, because in that case, any date that isn’t verified or standardized can be subject to (the wrong) interpretation, like when Gramps tries to make sense of 6.5.2033. And Ancestry does warn you about such dates, so if you persist, well, the consequences are for you, so to speak.
From here, I see a much bigger problem, which is to keep things up to date. Converting dates in a GEDCOM file from dd.mm.yyyy to dd mmm yyyy takes just a second here, and when I do that, on the file that Walter sent me, there are just a few dates left that need manual correction. But this process will have to be repeated whenever you add more data on Ancestry, because there is no easy way to detect updates.