18 replies to this topic

[SomebodySmart]

For the date of birth, if I am compiling one marriage or death record after another (or birth records which give the ages of the parents) let the user enter

 

1940-86

 

and have the machine convert that to

 

calculated 1854

 

to reduce keystrokes.

 

My database, BTW is getting bigger and I have newfound cousins contacting me to collaborate on connecting lines. Users should consider, depending on the size of the ancestral town and the available records, compiling the whole set rather than searching back and forth through old indices.

[Renee Zamora]

That looks to close to a date range to me. On the date calculator you can select the Start or End date so it populates into the field for you. 

[John_of_Ross_County]

Or just have a pocket calculator handy.  Works fine for years, but of no help if you need months and days.

[TomH]

SomebodySmart, are you aware that the Date Calculator is available from a Date field in Edit Person window, via clicking on the calendar icon on the right side? 

From Date field, 2-clicks to calculator. 

Tab twice to End Date: and enter 1940.

Tab to Age: and enter 86

Click on Select Start to close Calculator and populate the Date field with 1854.

Edit Date with modifier "calculated" or "calc"

 

Your proposal could save a couple of clicks and tabs but, to amplify Renee's point about format, the Date field already has to accommodate a great variety of valid date formats. It mistakenly accepts 1940-86 as a valid (but meaningless date or a reverse date range) but treats 1854+86 as a (invalid) text date. To enhance it to distinguish the minus hyphen from a range hyphen from a Y-M-D separator could be very tricky.

 

What might be more effective would be to break out the Date Calculator as a non-modal window or even as a separate utility so it is always open and just rely on the Windows clipboard to copy the calculated date. As it stands, I think the Date Calculator is a very efficient design apart from accessing it and it is hard to find an online app that is as good. I looked at several, none of which would accept "1940" without a month and a day, usually in separate fields.

[Vyger]

That looks to close to a date range to me. On the date calculator you can select the Start or End date so it populates into the field for you. 

 

I would agree with Renee regarding this looking like a range, if not I would not have anything so broadly estimated.

 

Whilst the Rootsmagicians fingers are busy I would like to re-iterate a few things about Date Calculator;

 

Firstly I would personally prefer the Calendar button in the date field of Edit person screen replaced or redirected to the Date Calculator, provide a user option or remember the last used. Invariably I am clicking this button during date calculation and I am very rarely choosing the date from knowing the day of the week so always need to make the additional click for the calculator.

 

Secondly I would like to see the Rootsmagic Date Calculator correctly apply a date range where age in years only is entered. For example the UK and Ireland Census return for 1901 intended to describe person status as of midnight of 31 Mar 1901, and age of individuals was only recorded in whole years. So for a 56 year old on that census the accurate birth date span (based on the recorded information) is Bet 1 Apr 1844 and 31 Mar 1845 and not 31 March 1845.

 

So please treat 56 years differently from 56y, 0m, 0d, and calculate a date span.

Treat 18 months, perhaps on a death registration, differently from 18m, 0d and calculate a date span.

 

I find this important on UK&Ire census returns where the year of birth from the calculation span two years and in the case above could be Q2 1844, Q3 1844, Q4 1844 or Q1 1845.

[Trebor22]

 

 

Secondly I would like to see the Rootsmagic Date Calculator correctly apply a date range where age in years only is entered. For example the UK and Ireland Census return for 1901 intended to describe person status as of midnight of 31 Mar 1901, and age of individuals was only recorded in whole years. So for a 56 year old on that census the accurate birth date span (based on the recorded information) is Bet 1 Apr 1844 and 31 Mar 1845 and not 31 March 1845.

 

So please treat 56 years differently from 56y, 0m, 0d, and calculate a date span.

Treat 18 months, perhaps on a death registration, differently from 18m, 0d and calculate a date span.

 

I find this important on UK&Ire census returns where the year of birth from the calculation span two years and in the case above could be Q2 1844, Q3 1844, Q4 1844 or Q1 1845.

Not forgetting the 1841 census rounded adults ages down to the 'nearest 5' so a different spread would be required here.

[Vyger]

Not forgetting the 1841 census rounded adults ages down to the 'nearest 5' so a different spread would be required here.

 

There are many variations but treating 56y the same as 56y, 0m, 0d is just wrong in my opinion, with missing data it can only be assumed as an approximation and would save me a lot of typing if correctly applied.

[TomH]

My reaction to seeking precision for the date span is quizzical. Is Bet 1 Apr 1844 and 31 Mar 1845 a better approximation than Abt. 1845? On another Census, the age may point to a different year or span. Maybe with a bit of AI and fuzzy logic, a Date Calculator could know that it is a Census Date that is the reference, know the date range over which the Census was taken and the rules the Census takers were to follow, divine something about the statistical accuracy of ages reported in the Census and offer up a Birth Date complete with standard deviation and probability of being right (e.g., 9 times out of 10 or whatever).

[TomH]

BTW, there is a "Census Age Calculator" that "knows" the UK Census dates at http://toshop.com/go/c.census-calc 

[Vyger]

know the date range over which the Census was taken and the rules the Census takers were to follow, divine something about the statistical accuracy of ages reported in the Census and offer up a Birth Date complete with standard deviation and probability of being right (e.g., 9 times out of 10 or whatever).

 

Some countries are more efficient in the recording of their census returns, like midnight on a certain date, not sometime between June and September

 

On a serious note Tom, using People View I find seeing the Bet 1 Apr 1844 and 31 Mar 1845 grouped with other approximations much more informative, if I had the inclusion of Given Name and an extra sort field that would be even better but another argument. If you accept that a non exact age description was declared on a certain date then the approximation is the closest factual return based on information which I know could well be a lie. At present Rootsmagic Date Calculator returns 31 March 1845 for a 56 year old on the 1901 Ireland census, this is simply incorrect.

 

In the case of a death on 31 March 1901 where the age of the child is noted as 18 months Rootsmagic Date Calculator gives me a start date of September 1899, no day presumed as there is no 31 September. I have seen US statistical records where Y,M,D's were noted as age but never found one to be completely accurate yet so probably more misleading than helpful.

 

I'm simply asking for a factual answer from Date Calculator based on the user input, I know my argument is a mathematical and logic based one but it's easy to program. So what I'm stating is that Rootsmagic Date Calculator should not make presumptions when some components required to enable the return of a precise date calculation are not entered so missing. I wouldn't expect a mapping program to presume zeros for Minutes and Seconds where I had only entered the Degrees, would you have a different opinion?

[Vyger]

I have started a new Name group, I import census records with the approximated dates from whole year as previously, civil birth registration facts and marriage facts.

 

Then I work to link and merge the records based on the information to hand. It's a system I find works well but only as good as the quality of the information to hand.

 

 

[TomH]

A "between" date always sorts ahead of any date within its range, including the start date. Duplicate Search Merge makes no distinction between a "between" date and its start date - you get to set the window width (default +/-2 yrs) for which there is a match between its start date and any other date type for the matching fact type. I just fail to see how the "between" date is superior to an "about" or "circa" date for DSM or visual inspection in the current RM7, with one possible exception... the Timeline View graphic does show ranges but is not very useful as you can see but one fact/event at a time. 

[Vyger]

 I just fail to see how the "between" date is superior to an "about" or "circa" date for DSM or visual inspection in the current RM7, with one possible exception... the Timeline View graphic does show ranges but is not very useful as you can see but one fact/event at a time. 

 

Tom, I think you may be thinking in terms of sort dates, please correct me if I have assumed incorrectly, but by definition "between" is more concise than either "about" or "circa" imo.

 

To reassert and return to my original Date Calculator wish, if I ask what age you are are and you reply "56" is is NOT logical for me to assume today is your birthday.

[TomH]

Tom, I think you may be thinking in terms of sort dates, please correct me if I have assumed incorrectly, but by definition "between" is more concise than either "about" or "circa" imo.

Yes, I did bring Sort Dates into the picture because the SortDate controls how Dates are sorted and, I suspect, it (or its algorithm) is in play in Duplicate Search Merge comparisons. Even if the latter is not the case, I doubt very much that DSM makes use of anything other than the Start Date for Between-and or From-to or other date ranges. And it may only be looking at the year of the date because the tolerance setting is set in units of years, nothing finer. Because your justification for wanting the calculator to deliver "between-and" is based on how it helps with matching other events having a single or range date, I'm pointing out that it is no better at doing so than a single date with a modifier (about or circa) that indicates it is an approximation. In fact, "between" implies a hard-bounded range unless you additionally fuzz the bounds with "about", e.g. "Bet abt 1 Apr 1900 and abt 31 Mar 1901". For DSM, a date of 1900 and a tolerance of +/1 1 year spans that entire period and then some or set it to 0 to cover the one year.
 
"Abt 1900" looks a lot more concise than "Bet  1 Apr 1900 and 31 Mar 1901".

 

To reassert and return to my original Date Calculator wish, if I ask what age you are are and you reply "56" is is NOT logical for me to assume today is your birthday.

You can assume what you will. Maybe I rounded up from 55y 7m (as an engineer, I tend to round up) or maybe I gave you the most significant digits from my age of 56y 11m 31d (damned if I will admit to 57 until there's no escape). You could logically calculate/estimate my birth date as "Bet 21 Dec 1961 and 20 May 1963" or as "Abt 1962".  If I was truthful in saying 56 and my birth certificate showed a date in the "between" range, then a tolerance of +/- 1 year will let DSM match it to "Abt 1962" but not to the "between" date if my birth date was actually in 1963 (on the assumption that it is +/- 1 year from the year of the Start Date or from the numerical value actually stored in the database SortDate field). Regardless of that assumption, I may have lied about my birth date or got it wrong, as was oft the case for people providing info to the enumerator, especially for other people in the residence.

 

Setting aside having the  calculator compute a "between" date from a Census date and age, what I would agree with is that the calculated result should have no better resolution or accuracy than the least resolution of the two operands. Currently, the calculator appears to ignore the resolution of the Age operand and delivers the result to the resolution of the Date operand. Maybe that's the  crux of your complaint. If the End Date is 2018, an Age of 56 y produces "1962" as the Start, while "20 Dec 2018" as the End results in Start of "20 Dec 1962" when it should be no more accurate than "1962" and could be reasonably expected to report "Abt 1962". It does produce "1962" from a Start of "2018" and a full resolution age of "56 y 11 m 31 d"; the date output res is governed by the date input res only.

 

And BTW, the date calculator supports "between" dates in that it will output one if one was entered in the other date field. So you can start with a "between" date and get one calculated from an age but the resolution may be unacceptably high.

[TomH]

Five years back, I created this test file that used most of the date modifiers when testing out what we deduced was the algorithm for computing SortDates.

SortDates (2013-01-01).rmgb RM6 database with samples of most date formats. I just realised that it did not include compound modifiers such as "Between about date and ..." - the number of possible combinations is enormous. I've not tested the Date Calculator to see how many modifiers it supports.

[kbens0n]

Up late reading these posts. Was curious about event dates vs. sort dates. Read the Help file on date formats (pretty well-documented and amplifies RM's flexibility).
Keyed in on part of very last sentence:

Note that these "dash" dates sort before a plain sort date

Just to confirm, I created a database with nine John Does ( 8 born Christmas day ...9th born after Xmas ;-) with varied Birth date types.
To help differentiate, I appended Rec# to surname and copied Sort date to (Birth)Place so that generated Timeline(Chronology) report showed them, then
edited the text output column names for clarity. Yup, "dash" dates sort before a plain sort date, LOL, and obviously in conjunction with the event date.
The event date sort takes some digesting. Here you go:


 
 
NOTE: Also, just for grins checked some of the valid RootsMagic date inputs and their displayed output:

1 Apr 1844 - 31 Mar 1845 shown as 1 Apr 1844–31 Mar 1845
1 Apr 1844 and 31 Mar 1845 shown as Bet 1 Apr 1844 and 31 Mar 1845
1 Apr 1844 to 31 Mar 1845 shown as From 1 Apr 1844 to 31 Mar 1845

About 1 Apr 1844 - 31 Mar 1845 shown as Abt 1 Apr 1844–31 Mar 1845
About 1 Apr 1844 and 31 Mar 1845 shown as Bet abt 1 Apr 1844 and 31 Mar 1845
About 1 Apr 1844 to 31 Mar 1845 shown as From abt 1 Apr 1844 to 31 Mar 1845

Between 1 Apr 1844 - 31 Mar 1845 shown as Bet 1 Apr 1844 and 31 Mar 1845
Between 1 Apr 1844 and 31 Mar 1845 shown as Bet 1 Apr 1844 and 31 Mar 1845
Between 1 Apr 1844 to 31 Mar 1845 shown as Bet 1 Apr 1844 and 31 Mar 1845

Calculated 1 Apr 1844 - 31 Mar 1845 shown as Calc 1 Apr 1844–31 Mar 1845
Calculated 1 Apr 1844 and 31 Mar 1845 shown as Bet calc 1 Apr 1844 and 31 Mar 1845
Calculated 1 Apr 1844 to 31 Mar 1845 shown as From calc 1 Apr 1844 to 31 Mar 1845

Circa 1 Apr 1844 - 31 Mar 1845 shown as Ca 1 Apr 1844–31 Mar 1845
Circa 1 Apr 1844 and 31 Mar 1845 shown as Bet ca 1 Apr 1844 and 31 Mar 1845
Circa 1 Apr 1844 to 31 Mar 1845 shown as From ca 1 Apr 1844 to 31 Mar 1845

Estimate 1 Apr 1844 - 31 Mar 1845 shown as Est 1 Apr 1844–31 Mar 1845
Estimate 1 Apr 1844 and 31 Mar 1845 shown as Bet est 1 Apr 1844 and 31 Mar 1845
Estimate 1 Apr 1844 to 31 Mar 1845 shown as From est 1 Apr 1844 to 31 Mar 1845

From 1 Apr 1844 - 31 Mar 1845 shown as From 1 Apr 1844 to 31 Mar 1845
From 1 Apr 1844 and 31 Mar 1845 shown as From 1 Apr 1844 to 31 Mar 1845
From 1 Apr 1844 to 31 Mar 1845 shown as From 1 Apr 1844 to 31 Mar 1845

Say 1 Apr 1844 - 31 Mar 1845 shown as Say 1 Apr 1844–31 Mar 1845
Say 1 Apr 1844 and 31 Mar 1845 shown as Bet say 1 Apr 1844 and 31 Mar 1845
Say 1 Apr 1844 to 31 Mar 1845 shown as From say 1 Apr 1844 to 31 Mar 1845

[TomH]

Expanding on the database I cited above, here is a SQLite query showing examples of the different kinds of dates that it supports with 3 additional examples of compound modifiers using "between", i.e.,

• between abt date1 and date2
• between date1 and abt date 2
• between abt date1 and abt date2

Sort Date evaluates all of these the same as 

• between date1 and date2

The Details column is what I entered in the  Edit Person Date field, plus a comment in some cases.

The Date column is what RM stores for the Date entered in the edit Person Date field.

The SortDate column is what RM stores for what is in the Edit Person Sort Date field; in these examples, what RM automatically filled in.

 

The results are sorted on the SortDate column which is what RM sorts on.

 

Note that all of the approximate modifiers for the 13 Jan 1921 date have its SortDate value. 

All of the approximate variations of "Bet 13 Jan 1921 and 25 Jan 1922" have its SortDate value.

All of the date1-date2 range dates that start with 13 Jan 1921 and with or without an approximation modifier sort before any single date variant of 13 Jan 1921.

[Vyger]

Setting aside having the  calculator compute a "between" date from a Census date and age, what I would agree with is that the calculated result should have no better resolution or accuracy than the least resolution of the two operands. Currently, the calculator appears to ignore the resolution of the Age operand and delivers the result to the resolution of the Date operand. Maybe that's the  crux of your complaint. If the End Date is 2018, an Age of 56 y produces "1962" as the Start, while "20 Dec 2018" as the End results in Start of "20 Dec 1962" when it should be no more accurate than "1962" and could be reasonably expected to report "Abt 1962". It does produce "1962" from a Start of "2018" and a full resolution age of "56 y 11 m 31 d"; the date output res is governed by the date input res only.

 

It wasn't a complaint, just an observation I thought was worth pointing out when this subject was under discussion.

Aside from the wild inaccuracies we deal with day to day in my experience when someone is asked their age they reply in terms of completed years or then qualify "I will be 57 on my next birthday" or "I was 56 last week" Therefore I believe the completed years of life are what was intended to be recorded on the census return and in the absence of any other supporting dob source this has to be my starting point and as accurate as possible. Nothing is exact in this business and Abt 1845 would be more acceptable in a date calculator return for someone recorded as 56 on the 31 Mar 1901 than returning 31 Mar 1845 even though statistically the person was three times more likely to have been born in the previous year of 1844.

 

This was no big issue or complaint, I was merely asking that the date calculator treated 56y differently from 56y, 0m, 0d, so your summary above on accuracy describes that very well.

 

But before we leave this subject suspecting sort dates are more in play with DSM and other logic, would Bet 1910 and 1950 having a sort date of prior to 1910 be seen as a problem?

 

Should it not have a sort date more akin to that of 1930?

 

[TomH]

After some more examination, I'm inclined to think that Duplicate Search Merge ignores Sort Dates and operates only on the Date column and, likely, only the year of the first date in the column.

 

Here is a screen shot of DSM results for a max span of 1 year between Births for 8 Joseph Blows. They include pairs of births greater than 1 year apart if the month and day were included whereas a max span of 0 includes only those pairs where the year of the first date in Date for the Primary matches that of the Secondary.

 

 

The highest score of 18.0 is reached by any pair of dates that match on that portion of the Date string in positions 4-11 containing yyyymmdd. Thus, "1929" and "Abt 1929", both stored as "19290000" score 18.0 as does a pair of full resolution dates such as "14 May 1930" stored as "19300514".