Corrupted data for these burials renders sources of no use

Paul W

There are almost two pages of these records - see https://www.familysearch.org/search/record/results?treeref=GSL3-SCN&q.surname=Wrightson&q.surname.exact=on&q.deathLikePlace=cramlington&q.deathLikePlace.exact=on&count=20&offset=20&m.defaultFacets=on&m.queryRequireDefault=on&m.facetNestCollectionInCategory=on.

This information would prove so useful, but corruption of dates somewhere in the process have made them rather pointless. Is there any way of giving this matter attention so the events can be identified and attached as sources?

Paul W

@Coleman Patty Thank you for responding to this. I raised the point last October and am pleased to find the issue has been addressed.

(See https://www.familysearch.org/search/record/results?q.givenName=jessie&q.givenName.exact=on&q.surname=wrightson&q.surname.exact=on&q.deathLikeDate.from=0017&q.deathLikeDate.to=0017&count=20&offset=0&m.defaultFacets=on&m.queryRequireDefault=on&m.facetNestCollectionInCategory=on - 9th result down - the coded date has now disappeared and the correct one is shown.)

Jordi Kloosterboer

I noticed that the date range is 1682-1951, so putting burial years in the form of or statements could be an answer. So 1701 or 1801 or 1901 for the one that was buried in 0001.

Paul W

Thanks for the suggestion, Jordi, but the "date" shown certainly gives no clue as to the year. For example, an individual shown with a 0026 burial died in 1906 and one with 0005 shown died in 1931! I'm hoping an employee is following this and can refer the problem to the the appropriate FS section for attention.

Update - just found an actual burial date of 18 Sep 1904 for a Jessie Wrightson whose burial "date" is shown as 0017 in the "source".

Jordi Kloosterboer

Paul, ah ok, I just assumed they used the last two digits of the year. That's weird they are scrambled like that.

Nvpattt

@Paul W Do you feel like the situation has been taken care of?