Bug Report: TreeShare / Import Strips BC Suffix from DatesIssue: When importing or syncing a family tree containing individuals with ancient “BC” years, the RootsMagic import engine completely strips out the “BC” / “B.C.” text suffix.Result: It encodes the year incorrectly as a positive binary date integer (AD). For example, a person born in “400 BC” is imported as "400 AD."Impact: For users with deep ancient, royal, or biblical lineages, thousands of dates are instantly corrupted. Manually correcting these dates one by one is impossible due to the sheer volume of people affected. Database tools (Rebuild Indexes) do not resolve this because the data string is lost during the initial API transfer/import process.Please log this with the development team to update the data-ingest logic so it natively reads and retains BC suffixes.
the original person on familysearch have bc in it; but rootsmagic strips it and make it an ad year which is problematic
Do you have the FamilySearch ID for them?
LD8Z-1HS for example; if you try it on anyone with bc years; the same glitch will happen
Thanks, confirming this has been reported to development.
May I ask… Surely every date type has already been tested and is in the test plan for each major release…??
Not like there’s a boatload of people, (w/ BC dates), that might be considered a test reference standard not susceptible to change or deletion.
i tested with every person with bc; and it omits out
So you’d hope. Question is when was this bug introduced? Was it June 27 when FamilySearch upgraded their backend? Or does it go back much further? When was the last update that touched on changes to the FamilySearch UI and API?
9.1.4.0 Apr '24 Fixed: Several FamilySearch issues
9.1.0.0 Nov '23 New: Streamlined Ancestry and FamilySearch login using OAuth technology - doesn’t seem related to the date issue
9.0.3.0 Fixed: Crash in FamilySearch compare relations screen when choosing to match with FamilySearch
Fixed: Several FamilySearch issues
We know it’s not the fault of the API. I just tested an import using Ancestral Quest 16 and it preserved BC dates.
We know that RM8 successfully imported BC dates - I have a file from a user that downloaded it in 2022 with RM8. In RM11 FamilySearch Central, the RM Person has the original BC date while the matched FS Person shows an AD date.
So the bug must have come about in one of those “Fixed: Minor bugs” updates. Maybe it’s very recent - it has not been reported before this?
And I came across a rather surprising difference in the BC-AD mistake. The numeric values differ by 1. Maybe that’s a year 0 effect.
Three tests for possible corruption:
-
Does a BC Date uploaded from RM create an AD date in FS? NO
-
Does a BC Date imported from FS create an AD date in RM? YES
The Death event on My FamilySearch Person displayed as 102 (AD) is actually 103 BC when viewed in FS, matching what is in the RM tree imported by RM8. Adding the Death fact as a new event in RM shows the conversion of the BC Date from FS to the AD Date in RM. -
Does the update from RM to FS of this corrupted Death date corrupt the FS Death event? YES
And FamilySearch Central looks no different on the FS side.
So there is lots of potential for corruption of dates in both directions.
To publish software that interacts with the FamilySearch API, developers like RootsMagic must initially obtain certification. There must be no re-certification process for new versions because, If there were, RM11 would fail.