I have imported a large amount of persons with dates, which are formatted such as “3 juni 1840”. (day[number] month[text] year[number]). Gramps don’t seem to register this, is there any way to convert all of them into a compatible format without changing them one by one manually?
When you installed Gramps, did you opt to install the language file used for that Calendar?
I use English and do not run into other languages very much. But it is possible that the importer may need the language support files to validate properly.
You may try to run Gramps in Dutch or German, because those are languages that use “juni” as a month name. I’m Dutch myself.
In principle though, program should always write English 3 letter months names as they appear in the GEDCOM standard, meaning that this “juni” entry is a program or user error.
I have the program in swedish so it can recognize the month correctly, but it seems it needs to have years first and days last for it to be a valid date, which I don’t have.
You might need to change your Gramps Preferences to have the Date format in the Display tab to use that ‘Day Month Year’ order. (Seemly unlikely that this will make a difference, but it is worth a try.)
Gramps has an idiosyncrasy in this Preference item: changing Date format requires restarting Gramps.
I understand what you mean, but that is not the case. Years first is a display format, which you can set in Preferences, and you can set that to the right order, and try the import again.
If that doesn’t help, the easiest solution is to load the GEDCOM file in a text editor, and replace all Swedish month names with the names that are listed in de the GEDCOM standard:
JAN | FEB | MAR | APR | MAY | JUN
JUL | AUG | SEP | OCT | NOV | DEC
If you do this automatically, it will replace month names anywhere, also in notes, or when they appear in person and location names, so you may need to be a bit more careful, and do some sort of interactive replace. Your ultimate goal should be that only lines starting with DATE are affected, which is easy with a small piece of software or an AWK script.
I’m getting old.
I ran into this issue when I was testing the download from the LDS Tree database. All of the dates were valid, many just were not in any Gramps format and displayed in bold.
I just tested it again. Running the Check and Repair did not work. Changing the format as suggested by @emyoulation did not work. After the import of the GEDCOM I tried to import that database’s .gramps backup file into a new database. It did not work.
The only thing that worked was to open the Event record and simply saving it reset the date format to the format set in Preferences.
Unless someone else knows how to nudge all the event records, I do not know how to this in bulk.
Do you mean the downloader that you can run from the command line? The one written in Python?
I download lots of branches with Ancestral Quest or RootsMagic, and when I export those to GEDCOM, most dates are right, except for date ranges, which seem to appear as FROM TO instead of BETWEEN AND, which is what they should be. The only dates that go wrong there are the ones where a FamilySearch user didn’t care about fellow users, and entered dates in his own language, instead of English. And the other ones are where a person is just marked as deceased, and that word appears in the date field.
Most errors can be easily cured with a text editor.
There was an earlier thread.
OK, that’s what I meant. I don’t understand why it would confront you with bad date formats however.
FamilySearch also allows unvalidated date text as a string, not a date data type. Like Gramps, it marks strings as unvalidated and expects a human to clean that up. (And they have a recent bug that doesn’t continues to store a validated date in string format during their ‘hint’ confirmation process. Users have to edit it again to convert the data type.)
And, like Gramps, FamilySearch tries to maintain display of the calendar type & language used during data entry. Unlike Gramps, they do not have an integrated export functionality, data interpretation is left to 3rd party developers. (Some using scrapers and others using FamilySearch’s under-developed API.) FS ambiguities created during export are a low priority.
@emyoulation I know how FamilySearch works, although this bug is new to me. And in my experience, bad dates are quite rare, at least when I download new brances with Ancestral Quest or Rootsmagic.
So, if @DaveSch writes about many dates, and I see just a few, I really wonder what’s going on.
1 Like
This is what I get. The errors are on dates with the full month. But even when I switch my date format to DD Month YYYY, they still display as error. It is only the event edit that cleans the date from the text to a recognized valid date.
1 Like
@DaveSch thanks. Can you give me FS ID’s for a few of these people, so that I can check how they download with Ancestral Quest or RootsMagic?
In this particular case, i would be quite easy for the importer to trim the month names after 3 characters, or accept full English names as valid, but that won’t work for other languages, for example in Dutch, where we write Mei for May, and Juni for June.
Changing the importer should not be a big deal for English, I think.
Note that for me, where the editor accepts local month names only, editing doesn’t help, because it only accepts Juni and Juli, etc. And that is a nuisance when I do copy pastes from English speaking sites.
I really think @emyoulation clue that the dates that display as errors are plain text and not entered as valid dates.
And the one time I tested the download, it easily took me 4 times as long to clean and then import/merge than it would have taken to hand enter the same information. I am not inclined to use these tools.
I ran a test with my ancestors, and with the ID that you gave in a PM, and for both I saw that GetMyAncestors export loads of long month names, and triggers a lot of errors that way. RootsMagic does not do that however, which suggests that their FS download knows how to deal with long English month names, and makes sure that they are standardized, and exported according to the GEDCOM standard.
@emyoulation is right about some FS bug too though, because in my own tree, I found two dates that go wrong with RootsMagic, and that is because FS seems to store them with Dutch month names like Januari and Mei. When I check these on-line, they appear to be standardized, but it looks like FS is rather confused about that.
This means that when you really want to import data from FS, it is way easier to use Ancestral Quest or RootsMagic, or another certified program. And in fact for both, the free version will do, and RootsMagic works quite well in Wine too.
Another thing is, that it would be nice to make the Gramps import more forgiving, so that it accepts long names in English, and in the user’s locale. The CSV import does that already, and supporting the English version will not only solve problems with GetMyAncestors, but also with GEDCOM downloaded from Ancestry, which also have loads of long month names in them.
And incidently, RootsMagic can download from Ancestry too.
There’s a discussion of using SuperTool scripts to rearrange text containing formatted dates that ordered differently than Gramps recognizes. Then passing that text back through the date parser.
The problem is caused by the original import file having those Dates flagged as a text “phrase” rather than a structured date value. This is used when the data cannot be understood by GEDCOM’s very strict parser.
While the cited “3 juni 1840” does appear in GEDCOM’s expected “day month year” order, that data has 2 violations for expected structured date format:
- GEDCOM standard specifically requires the use of English 3-letter month abbreviations, not the full month name.
- Non-English month name abbreviations are not officially supported in the GEDCOM format.
While Gramps date parser is far more flexible, the GEDCOM file explicitly indicates that the Date data is a “phrase” and should not be parsed.
But you can force Gramps to try to parse the string into a structured date value anyway.
For single occurrences, the easy way is to click in the date field in an Event Editor and press Enter or Tab.
If there are more than about 10 dates that need to be re-parsed, then you might to use some automation. The SuperTool add-on is a flexible tool for scripting such automation.