They are are NOT in the correct format for GEDCOM. Valid in GEDCOM uses the dd MMM yyyy format (or the title case dd Mmm yyyy in GEDCOM 5.4 variant) and specifies English. As before, the dd.mm.yyyy is considered ambiguous unless the dd value is greater than than the 12th day of the month.
This is a continuation of the invalid imported date re-parsing conversation in the following thread. (Although they were dealing with ambiguous dates from an Italian rather than German GEDCOM.)
And this issue has the same complication that this will have a short-lived interest in resolving the import problem. (Once this particular import case is resolved, interest in evolving the tool from a crude hack to an elegant and flexible tool will die. So we have to take advantage of the short-lived interest to evolve the old solution hack, not start all over again.)
Perhaps this cycle of the evolution could pick up the development thread? Maybe add the ability to list examples of invalid dates from the database and offer the user and option to specify which decimal delimited pattern (‘dd.mm.yyyy’, ‘mm.dd.yyyy’, ‘yyyy.mm.dd’, ‘yyyy.dd.mm’, or the no-leading-zero ‘d.m.yyyy’ ‘m.d.yyyy’ or maybe even the evil ‘d.m.yy’ with a century selector) to use for the re-parser?
Again, using the PortableApps fork on a Windows box (or emulator) was the starting point because it includes all the languages Gramps supports.