Converting Julian Dates to Gregorian
The original document for MSPC-D1Y has UK marriage entries from 1679 to 1681. Instructions for the indexing project say:
"England adopted the Gregorian calendar in 1752. Prior to 1752 in England, the year on the Julian calendar began in March and continued to the next February. This would mean that the 3rd month in 1730 would be May. In the Gregorian calendar adopted in 1752, the 3rd month would be March. When indexing records for this project, please convert the Julian calendar dates to their Gregorian calendar equivalents. Click here for help converting dates."
The problem with doing this is that dates in the index would not match dates in the document. This would make it more difficult, or at least more inconvenient, to find an entry in the document by searching for a date listed in the index. Date is the easiest thing to search in the document. Names are harder. The mismatch in dates would likely be confusing. I would suggest simply labeling the entire index for the document as having Julian dates rather than Gregorian dates, but make dates in the index and the document match. Then an entry in the document could be easily found by searching for a date listed in the index.
I would like to respectfully suggest that indexers should not be burdened with having to convert dates. That should be the responsibility of those who are trying to interpret data from a document.
Comments
-
Hi Tom.
Your concerns echo may similar comments in Community, but while it goes against the current indexing practice of 'writing what you see', the client obviously specified the date change when agreeing the contract for the indexing to be done - hence the project instructions.
I have indexed and reviewed a large number of these records and find that most have either the Gregorian date (post 1752 ones), or the written month name, meaning that the only changes to be made would be to the year number for the first three months in pre-1752 records.
There are obviously some of the earlier records that have the month depicted by a number rather than a name, and these would take a little longer to do. These could easily be returned for someone else to index if you felt they took too much of your time.
Thanks for all the work you are doing in indexing these vital records.
Kind regards,
Barry
0 -
If what Barry says is correct, I would plead with "FamilySearch" to politely decline to accept an offer (from a "client") to have any involvement in undertaking work on such a project. I believe this situation can arise (who knows in this particular example, FamilySearch would never reveal specific details of a contract) even when it relates to a particular "whim" of the person writing the project instructions. Either way, this is not correct practice and I believe all organisations should avoid such at all costs. How confusing if the researcher finds what appears to be the "same" event, yet indexed with a different date, in another indexed collection - possibly even on the FamilySearch website! No, I'm afraid I would suggest a complete rebellion on this issue - advising all indexers to boycott such projects altogether. Seems rather drastic, but "genealogy this ain't" - so I find the situation (of any organisation indexing, then ultimately publishing such data) to be completely unacceptable.
2 -
If indexers need to convert dates, reviewers would also need to do the same conversion again. Rather than put that burden on them, one possible solution might be to do the conversion by computer after indexing and reviewing are done, since after indexing, the data is computer readable. I would be happy to provide a description of the algorithm necessary and even a C++ subroutine that would do the conversion if this is a possibility.
0 -
@Tom Eccles does your algorithm cover transition dates in all jurisdictions?
For those not familiar with the issue, FamilySearch Research Wiki has an informative page including a table of transition dates. https://www.familysearch.org/en/wiki/Julian_and_Gregorian_Calendars
0 -
This issue started in December. It was not a well thought out plan and the instructions were changed after one individual emailed Support and the next day these instructions were added to the project. (I think that was in February). You can search in the Indexing community group and track the problem. The instructions were not well thought out or well-written, the original calculator that was attached was insufficient, and the current wiki (it that is the one that still is being utilized) is confusing.
We don't calculate dates any other time, why is this project so different? We type what we see. The idea of the algorithm that converts all dates involved sounds promising, except now some of the dates have been changed, and others have not. So, how would that work in an "if - then" situation? Sounds like a hot mess in the current collection being indexed... Maybe next time?
But, this definitely needs to be addressed at some point by Indexing Ops since the question and discussion comes up very frequently and never gets resolved.
4
