Set Sort Dates

On this page: Description, Why Does This Feature Exist?, Example, Notes, Log Format

Description

Set Sort Dates reduces the number of sort dates that must be entered manually to produce logical narrative reports. The program uses the tags with dates to determine reasonable sort dates for those without dates.

Set Sort Dates will not change existing sort dates, regardless of how they were set. As a result, it can not be used to alter sort dates set by a previous use of Set Sort Dates.

You should read this entire page before using this function. The program makes a number of assumptions and you should be aware of them and how they affect the result.

Thanks to Bob McMaster who was a diligent and patient beta tester for this function!

Step by Step

1. Choose Set Sort Dates from the function tree.
2. Arrange the tags in the tag list in the order that you desire. Use the Move Up button to move an event up, and the Move Down button to move an event down.
3. If you do not want the program to assign sort dates to certain event types, leave the checkboxes for those tags unchecked.
4. Click the [Set Sort Dates] button.

Why Does This Feature Exist?

In TMG, undated events may appear out of logical sequence when you have not entered a sort date. For example, an undated marriage event will appear before a dated birth event. You can correct the problem, and improve report output, by entering a sort date.

If you have imported data from some other program, you may have many events that would benefit from a well-chosen sort date. (Some programs hard-wire the sort sequence of certain events.) Unfortunately, entering them all can take a long, long time. If the people affected are not in your main area of focus, you may choose to never fix the problem.

As mentioned above, this program uses the tags with dates to determine reasonable sort dates for those without dates. The user can choose the desired sequence. For example, consider B-M-D-B. If we know any one of the four dates, we can put the others in sequence. Now add in another tag, say, Education. Maybe you decide that most of your undated Education tags should follow birth but precede marriage. You could set the sequence to B-E-M-D-B (where E is Education).

The program (a) never alters the sequence of events that have dates, and (b) never assigns an actual date; it only assigns sort dates.

The program will not eliminate all the manual steps necessary to fix tag sequences. It will reduce the number that must be fixed manually, and in my case, it made a big difference. Your mileage may vary.

Set Sort Dates: An Example

Assume that a person has 5 tags: birth (undated), marriage (undated), burial (undated), education (date=2 Jun 1880), and death (15 Jul 1917). Further assume that the user has selected the following tag sequence for the tags involved: birth, education, marriage, death, burial. The program would process the events in that order. The actions taken would be as follows:

1. The Birth tag would be assigned a sort date of 1 Jan 0100. The tag is undated and there is no tag that precedes it in the sort order, so the program assigns that date.
2. The Education tag would not be changed because it already has a date.
3. The Marriage tag would be assigned a sort date of 3 Jun 1880, one day after the date in the Education tag.
4. The Death tag would not be changed because it already has a date.
5. The Burial tag would be assigned a sort date of 16 Jul 1917, one day after the date in the Death tag.

Notes

Here are some things you should know about the program, including how it handles dual-principal events and how it uses parent birth dates.

1. The program assumes that dual-principal events "belong" to the person with the lower TMG ID. This is a significant limitation, so the program takes one extra step when processing dual-principal events. It calculates a date based on the lower numbered principal, as usual. If the calculated date is earlier than the other principal's primary birth date, the program adds one day to the other principal's primary birth date and uses that date for the event.
2. When Log Only is on, the program will not produce the exact same results as when Log Only is off. The problem lies (again) with dual-principal events. When an event is processed for the second time, the sort date will not be set. The program will choose a sort date again as part of a different set of events, and the new date affects subsequent results for the same person.

   This does not eliminate the value of the Log Only option, but you should take this factor into consideration when you review the results of the trial run.

3. When the program has events to modify for a particular person, it assumes a starting date of 1 Jan 0100. This date is assigned to the first undated event if there are no events that should be sorted ahead of it. If the current person has parents, and those parents have birth dates, the program will add 12 years to the most recent parental birth date and use that in place of 1 Jan 0100.

Log Format

The log format for this function is quite cryptic. I kept it that way mostly to keep the logfile size to a minimum. The following notes explain what it all means.

Here's a set of log entries from a run of the Set Sort Dates feature.

#8466, 0 n, 4 v
 I:  13722 Birth      11 Jan 1766|11 Jan 1766
 I:  13723 Death      01 Feb 1838|01 Feb 1838
 I:  13724 Burial     |
 I:  13930 Marriage   |
*C:  13930 Marriage   |24 Jun 1768 (O)
*C:  13724 Burial     |02 Feb 1838 (E)

The first line identifies the ID number of the person being processed, and the number of names and events that were analyzed.

#8466, 0 n, 4 v

In the example, ID #8466 has zero names and four events. In truth, the person has a name, but this feature ignores the primary name, because it prints first in most reports and doesn't need a sort date except under unusual circumstances.

The lines that begin with I: show the Input: the names and events as they exist in the DB. The events are not shown in any particular order.

 I:  13722 Birth      11 Jan 1766|11 Jan 1766
 I:  13723 Death      01 Feb 1838|01 Feb 1838
 I:  13724 Burial     |
 I:  13930 Marriage   |

There are four events, and so there are four I: entries. The columns, in order, are Record Number, Tag Label , and Dates. The record number uniquely identifies an event. The tag label identifies the type of event. The dates column shows the Date and Sort Date fields from the event, separated by a vertical bar (|). If the Date is missing, the entry will start with a bar; if the Sort Date is missing, the entry will end with a bar.

In the example, two events have dates: the Birth and Death tags. We expect the program to set Sort Dates for the other two events to make the events appear in the following sequence: Birth, Marriage, Death, Burial. The subsequent log entries show that is exactly what the program did.

*C:  13930 Marriage   |24 Jun 1768 (O)
*C:  13724 Burial     |02 Feb 1838 (E)

The *C: indicates that these are the Changes the program made. Two events were changed.

In the case of the Marriage event, the "(O)" indicates that the program assigned a sort date of "24 Jun 1768" based on the Birth date of the other principal, who presumably was born on "23 Jun 1768".

You may wonder why the program didn't assign a later date for the Marriage event; people rarely marry one day after they are born! There is a simple explanation. The program doesn't "understand" marriage events any more so than other events such as "Education", "Move", etc. It just knows that you have asked to place Marriage events after a number of other events, including Birth.

The "(E)" on the Burial event means that the program assigned "02 Feb 1838" by adding one day to the date of a previous event. In this case, the date of Death was "1 Feb 1838" so we know that was the previous event.

The values that occur in parentheses after a program-assigned sort date like E and O above are as follows:

Remember that these are sort dates! The program makes no claim that any of the events occurred on the dates shown; the dates are used by TMG to sequence the events, but sort dates do not appear in reports.