RealMac wrote: I would prefer to see the dates displayed in something like their original form (1734/1735, for example), while sorting on an internal "historical date" value that is not displayed. Also, we certainly don't want to impute double dating where the original date was reckoned from January 1. The solution to these concerns would seem to be (1) allow the user to enter a double date if appropriate; ... (3) store the date internally in "historical date" format (reckoned from January 1) for purposes of sorting only.
I found that should a child be born in say June of 1735 and then the death says the child died in February 1735, it causes all sorts of problems in the system. The indexing guidelines were set up to deal with this issue. I agree, the double date is the most accurate, or at least let us be allowed to edit the double date so that no child will die before they are born!!!
This is a very old topic, dating from August 2014. If your issue applies specifically to the indexing of such records, it is probably best to raise a new topic in the Indexing section of "Ideas".