There’s a fair amount of cleanup to be done with the exported GEDCOM data.
There are a lot of Dates that weren’t valid on the Ancestry system. They were saved as ‘Text’ rather than as a ‘Date’.
The valid records are in ‘d Mmm yyyy’ format. So a “5 Sep 1981” would be valid to their system but the Month fully spelled out (“5 September 1981”) or without the proper capitalization (“5 sep 1981”) was considered ‘Text’ by Ancestry when they exported. So they imported through the GEDCOM as text too.
Most software has a hard time parsing dates. And Gramps allows oddly formatted dates to be recorded as text too when the data is unclear. (Like if a date scanned comes in as “3 Mau 1865”. It could just as easily have been ‘May’ or ‘Mar’ in the original document. So keeping it as mangled Text is the right choice if you cannot access the original yet. So keeping imported text AS text might be the right choice in an automated process.
But… you can also force Gramps to re-run the date validation for an imported by adding a space to the end of the text string.
That is kind of a hassle to do manually for a lot of entries.
So you can use a script to force all the invalid dates (or even a selection of them) to revalidate without having to open every event individually. The SuperTool addon is an advanced tool for creating or running such scripts. The script is described in another thread. It leverages the add-on filter rule that looks for Events with Invalid (or Valid) dates.
There are also a lot (a LOT) of duplicate citations. Duplicates (of all object types) are a typical issue with GEDCOM. Merging with the MultiMerge addon gramplet is a lot easier than doing a dozen merges of pairs for 13 duplicates.