OK, thanks! Cross posting is a good idea, because Discourse gives us way more flexibility with messages, and also way more screen estate, to keep things clear.
I’m still in doubt about the right approach though. We have GEDCOM files with weird dates, caused by anomalities in other software, like Ancestry and RootsMagic, and we have things like the example that you gave for Brother’s Keeper, where people often use a slash to express some form of doubt. My late father did that too, to express that he wasn’t sure about the exact year, and I think that he did not use the slash to express a range, but rather two alternatives. I mean, that’s how we often use a slash on this side of the ocean, when it’s not Gregorian/Julian. That means that I might have a date like 18-10-2012/22.
Another thing that I often found is that he put a text behind the date, like RK for a baptism done in a Roman Catholic church. We write Catholic as Katholiek.
Date formats like these can better not be handled by the GEDCOM parser, because they are quite unpredictable, because they’re based on personal habits. And that suggests that they can best be handled by a tool, also for situations where one can assume that the author wasn’t aware of using the slash for Gregorian/Julian dates.
OTOH, I know that Ancestry writes long month names, when you export a GEDCOM from the site, so that anomaly is predictable, and can be handled by the GEDCOM importer. These months names are always English, so that any Gramps setup can handle it.
And statistically, one might argue that when non English month names appear in a GEDCOM file, they are often in the user’s own language, so that they can be parsed too, if that language is installed, which is the default in Linux and Windows.
Things can get a bit more difficult when there is a 3rd language, which can give dates like 10. März 1618. In this case, there’s not only a German month name, but also a dot behind the day, which is the equivalent of ‘th’, so 10. means 10th. That dot would be fine if it were used as a separator, like in 10.03.1618, but in this case it goes wrong.
I often find these by sorting all events on date, because with that sorting, all invalid dates appear between the empty and the valid ones.
All in all, I think that the proper approach may depend on the frequency of the errors, and their consistency. The long month names in Ancestry are a well known phenomenon, and dates in the user’s language are quite common too, so IMO, they should be handled by the GEDCOM importer.
The other ones are a perfect job for a tool, if there are too many for manual correction.