Birth/Baptism & Death/Burial Date Processing in RM9

RootsMagic
,
1

Hello.

I am having an issue with Rootsmagic Technical Support and would welce further involvement.

The problem I have encountered relates to new date processing in RM9.

I would preface these remarks by stating that I can only comment on the situation in the UK although I don’t expect other countries to be any different.

RM8 caters for the common situation where a baptism date is known but only the birth year is known. Unless a copy of the birth certificate is obtained (expensive and not practical for obscure relatives) or the birth date is recorded in the Baptism Register, the GRO Index (UK) is the most likely source to provide birth details.

However that index was originally compiled quarterly so is not 100% accurate because of the time allowed to register a birth. In some cases the birth could have taken place in the previous year with the GRO entry in Q1 of the subsequent year.

In the example I quoted to the Tech Team the baptism date was obtained from the Baptism Register and the birth date from the UK GRO Index. Both dates are valid because of the time allowed to register the event. The data input is:
Birth Dec Q 1851
Baptism 30 Sep 1851
Death Jun Q 1852
Burial 28 May 1852
RM8 was quite happy with this situation as it correctly recognized the sequence of events and that a baptism is always preceded by or is equal to the birth date (same for deaths & burials).

RM9 does not accept these conditions and creates an unnecessary Problem Report stating:
Born after Baptism
Burial 90 days after Death

The response from the Tech Team is to Use the Sort date but that only corrects the sequence of events and does not prevent the generation of the Problem Report.

The only way to prevent the Problem Report is to input a specific month rather than the Quarter, i.e, by recording the birth as July it accepts the data matches the RM9 validation checks BUT that is misleading (I accept “Q4 1851” is also misleading but – to me- indicates the correct REGISTRATION date).

I believe the RM8 validation is to be preferred as it results in the correct recording of Events and does not require addition User action to use Sort Date and/or resolve erroneous Problem Reports.

I also believe that a hierarchical approach which always sequence Birth before Baptisms before Deaths before Burials should be used. This would avoid having to use Sort Date when, for instance, an exact Death date is known but only the (assumed) burial month is known.

Interested to hear other views.

Andy

2

In RM9 we added Problem Alert “Burial after Death” and how many days. That is why RM8 seemed “happy” with it, because it wasn’t checking for it. Order of events may have not been checked in RM8 so that’s why it wasn’t catching that birth and baptism issue.

Quarter dates sort on the first day of the quarter.
First quarter, Q1: 1 January – 31 March (March Q)
Second quarter, Q2: 1 April – 30 June (June Q)
Third quarter, Q3: 1 July – 30 September (Sep Q)
Fourth quarter, Q4: 1 October – 31 December (Dec Q)

1 Like
3

With regard to the Birth-Baptism conundrum, when does the Dec Q begin? Oct 1. So the Baptism date of 30 Sep is earlier. How would you want that to be reconciled in some general way that would satisfy all combinations and all users? It’s like asking the program to examine the quality of your sources and decide whether there is an issue with the dates.

You can resolve it yourself. You could add another Birth event as Primary with the date set as Bef 30 Sep 1851 because you have evidence proving the Baptism date. You could also change your existing Birth event to Birth Registration, which is what the evidence really proves. Either way would resolve the Problem Report.

And the 90 days is because of the number of days since Dec 31, 1899 (or some other date) that RM uses to calculate time spans and sort dates. What day number should be assigned to a Q date? That of the 1st day, the middle day or the last day of the Quarter? It looks like the day number for the Quarter ending in June is that of early March if you correctly reported the problem as “Burial 90 days after death”, which seems opposite to the Birth Problem… It would be consistent if the burial was before death. But as those day numbers are invisible to us (not stored in the database), I cannot say for sure.

I took your example and entered it in RM7 in the reverse of the natural order and queried what gets stored in the database, sorted by SortDate:

Abbrev	Date	                    SortDate
Baptism	D.+18510930..+00000000..	6671853067198005260
Birth	R.+18510400..+00000000..	6671871758895677452
Death	R.+18520200..+00000000..	6672223602616565772
Burial	D.+18520528..+00000000..	6672274180151443468

You can see the Birth and Baptism are not in natural order and its Problem List reported “Born after Baptism”. Death and Burial are sorted the same as natural order and there was no problem reported.

The SortDate is not an elapsed number of days since some reference although that is buried in this position coded 64-bit number. See:
https://sqlitetoolsforrootsmagic.com/dates-sortdate-algorithm/

So I opened-converted the RM7 file in RM9 and got the same Problem list as you - the seemingly erroneous report of “Burial 90 days after Death”. That I don’t understand. Even the age calculations are strange:
image

1 Like
4

I have a lot of early UK ancestors–some were Baptized within a few weeks–some when they were 7 yrs old ( parents Baptized all 3 kids the same day) but the Minister recorded their births on the Baptism—IF I don’t know, I would also put before Sept 15 1851 ----You could go under general settings and uncheck show problem alerts on individuals — then if and when you need to , run the new problem search UNDER TOOLS on left hand side and just NOT run proper order of events for person and burial after death-- or just click not a problem and it won’t show up again…

5

I’m probably missing something here, but wouldn’t it be better if RM always listed Birth as the first event and Death and Burial (in that order ) as the last two events regardless of whether any date is known or entered? Any other event must be shown as falling between Birth and Death

6

That horse has already been flogged many times.

As for all facts being between birth and death, I don’t want all my facts between birth and death. I have certain facts such as probate, FindAgrave and obituary, and many others that I want after the death fact, which is where they go now.

1 Like
7

Confirming issue with Burial after Death dates when using Quarter dates has been reported to development.

8

That’s not quite correct. Rather, they sort between the last day of the previous quarter and the first day of the stated quarter. In fact, they sort equally with the 1st month of the quarter without a day number. That is, 3rd Quarter 2000 = Sep Q 2000 = July 2000

It has been noted in another topic that RM9 Help is silent on Quarter Dates.