ancestry->FSFT synchronization of events with date-ranges result in NO entry creation

LegacyUser

brentsweeny said: Third time's the charm, I hope: I originally opened a ticket on this, and they told me to add it as 'feedback suggestion' instead, so here goes:

When using the ancestry->FSFT synchronizing feature, dates from British civil registration records in 'quarterly' format (e.g. Jan-Mar 1852) don't transfer at all from Ancestry to FamilySearch Family Tree (whose standard for representing such dates is "From January 1852 to March 1852"). The FSFT changelog shows a source attached from that sync process, but the event isn't touched at all. I have screenshots of the sync page, the changelog event, and the (empty) event. This behavior (or lack of it) is extremely repeatable for any person and any type of event (birth, chr, marr, death, burial, etc.). It's not clear to me whether the problem is on the ancestry side (they seem to be uncomfortable with dates entered in that format, preferring only the [inaccurate] first month of the quarter, so they may allow you to enter it but not send it to FS) or the FS side (who may not accept it). If the FS engineers don't know where the problem lies, it may take someone with low-level access to the transfer procedure to see what's being sent to understand whether Ancestry is or is not sending it. I've submitted this concern (complaint?) to Ancestry as well, with the usual non-response. If anyone has a way to get their attention, I'd be happy to hear it, but that's another issue.

Can this be fixed somehow? Otherwise, if people don't doublecheck that the FSFT event actually got changed correctly, they would assume that it worked along with other data transferred at the same time. Until I saw that the entry wasn't being made, I've lost untold numbers of events for many people because of this broken mechanism. thanks. brent

LegacyUser

brentsweeny said: I just discovered another fact in this mini-saga: if I enter the date on Ancestry in the FS format e.g. "from July 1852 to September 1852", it does show up in the familysearch entry. That suggests to me, without being to see the details of the conversation between FS and Ancestry, that if the date is in a form that FS doesn't anticipate, like "Jul-Sep 1852", it barfs on the detail and doesn't enter anything--even the place if both date and place are provided. Obviously it does accept dates in multiple formats, just not that one. Because all British civil registration events are given in that format, can it be agree that that's also a legitimate expression of a date, even if not a "standard" preferred one? surely you don't accept *only* "standard"-form date and place information from Ancestry, so there must be some set of accepted forms.

LegacyUser

Tom Huber said: The handling of date ranges varies from program to program. I happen to use a fully certified personal family tree management program, but when it comes to handling multiple dates and date ranges, the system does not work particularly well.

That problem really has to be tackled from the interfacing program. The programmers of the program (Ancestry, in your case) have to work within the scope of the API (which is the interface that other programs use to access FamilySearch).

When you contact Ancestry, make sure you include concrete examples of the issue, wherein Ancestry can test the interface to make sure it is working correctly. I would also copy FamilySearch on the correspondence.

Note that Custom Events are the most troublesome for me. Those are established by the user and so that is the area where most of the problems are going to occur.

Keep in mind that dates are represented by numbers and as such, incomplete dates can also create no end of problems in transferring information. In each of those cases, I manually enter the information in FamilySearch FamilyTree, rather than depending upon the API to work correctly. Then I sync FSFT back to the original program and compare what came across.

LegacyUser

Adrian Bruce said: " if I enter the date on Ancestry in the FS format e.g. "from July 1852 to September 1852", it does show up in the familysearch entry."

I strongly suspect that a date like "Jul-Sep 1852" is not being accepted and processed "properly" in Ancestry to start with. It may look like it's there but I will bet that if you try to use it as a date (not sure how!) it won't work - it's just text that has no meaning as a date (it might turn it into 1852, I don't know).

I think that the key is to understand that the Ancestry date formats are, shall we say, inspired by the GEDCOM formats. (Plenty of programs work like this).

GEDCOM allows "FROM date1 TO date2" and "BET date1 AND date2", so "Jul-Sep 1852" is simply not acceptable in a GEDCOM based program - unless the program's been tweaked to extend the typed text and reinterpret it as a valid GEDCOM date.

FSFT strangely doesn't even accept BET ... AND ... formats - instead if you enter that manually, it offers FROM ... TO ..., which doesn't even mean the same in the English language.

1. I suspect that the chances of FS altering the date formats is slim - if they can't even cope with BET ... AND ..., there's little chance, I suspect, of them adding in a new one - it's actually not instantly simple because it needs to be translated to allow date arithmetic.

2. I suspect that you may have a problem even in the Ancestry tree - dates like "Jul-Sep 1852" will probably not be processed in the way that you expect. Who knows, it might get interpreted as 1852 or even Sep 1852 but that may be as far as it goes. I'm not sure how to tell how Ancestry is using that format.

3. "Jan-Mar 1852" isn't a standard for the English Civil Registration system - that may be how Ancestry presents it but others will do it differently. I think even the GRO aren't consistent, it depends which document you're looking at. (My software allows "Q1 1852" for input, for instance, but translates it into a GEDCOM standard format for storage).

4. "surely you don't accept *only* "standard"-form date and place information from Ancestry" - Personally I'll bet that that is the case - only the standard formats. But it would take a lot of digging in documents that I'm not familiar with to determine the answer.