I can understand that you did not expect this, but I just did a test with my own tree, and found dozens of bad dates in the GEDCOM file, which all had long month names in English, like June. And in GEDCOM, month names should always be 3 upper case letters, in English. That means that when I enter oktober, or 10, a proper GEDCOM export must write OCT, and nothing else.
Most software can do this, so that it can store proper dates, meaning dates that comply with our (local) settings, in some standardized format, which you donât see, except when you look inside the database, or in Gramps XML. And that means, that when your Gramps is configured to recognize 6/17/2024, it will store that as real date, and export that as 17 JUN 2024. It will also change the way itâs displayed when you change settings, after a restart.
This mechanism only works when Gramps can recognize the date, and if it does not, like when you add a text like ânot sureâ, it will not store it as a date, but as text. And you can recognize such a date in many views, because itâs shown in bold. Bad dates also donât sort like real dates in the event view, which is an easy way to find them. When you sort that by date, the sorting shows empty dates first, then the bad ones, followed by all the good ones, and thatâs why I can tell you that the Ancestry export had dozens of them.
When I downloaded the same tree with RootsMagic, and did the export with that, there was only one bad date left, and that was one with some extra text, so it was a bad date indeed.
I just made a test tree on Ancestry, where I had to enter dates as mm/dd/yyyy, and they were displayed as dd mmm yyyy in the tree, with English month names. And that suggest that Ancestry can recognize things, so it does not necessarily mean that any date entered in that way is wrong.
Anyway, in the end, the fastest way to find out, at least for me, is to sort the events by date, so that the bad dates are all shown on one page, or some more.
And hopefully, FTM is just as smart as RootsMagic.