Sort Date with Dash Suffix Doesn't Change When the Fact Date Changes

RootsMagic
1

The sort date for a fact in RM8 does not change when the date for the fact changes if the existing sort date includes a dash suffix. It seems like a strange behavior. I’m used to adding a dash suffix to the newly changed sort date in these circumstances, but I’m not used having to totally redo the sort date. It seems like a bug, but I wonder if it’s by design. And if it’s by design, I wonder why.

The sort date for a fact in RM8 does change when the date for the fact changes if the existing sort date does not include a dash suffix. That seems correct. I’m just curious why the presence of the dash suffix in the sort date changes the behavior.

2

Trying to figure out what you mean. Can you post a screenshot?

3

It’s too hard to explain with a screen shot. Instead, here is a 1:14 screencast.

Screencast, sort date not changing, 1:14

4

It’s not that it is a suffixed SortDate but that the SortDate has been manually changed that freezes it. RM7 overrides whatever is in the SortDate when the event Date is changed. Certainly is a change in behaviour and not one that I recall ever being requested.

5

I’m going to refine my observation of the SortDate behaviour. If Edit Person dialog sees that the stored Date and SortDate do not coincide, then it does not update SortDate when Date is changed. If you edit one or the other so that they do coincide, then the next time you change the Date, SortDate will follow.

In the UI, Date and SortDate are spaced about as far apart as they can be for events so visual comparison is not facilitated. For name-type facts, they are together and it is pretty obvious if they differ. For events, if the change to the Date is going to revise the SortDate, the latter gets the dot flag. One would need to be sensitive to its absence to be alerted that the SortDate will not follow.

6

Is 21 Apr 1942-3 a considered a valid date by RM8?

7

21 Apr 1942-3 is not a valid date, but it is a valid sort date.

The dash suffixes can be used in sort dates to place same day events in the correct order. Suppose someone was born, died, and buried all on 12 Jan 1903. That’s the way the birth date, death date, and burial date would be entered into RM. But RM wouldn’t necessarily order the events in the correct order of birth, death, and burial. The RM way of getting the dates into the correct order is to use sort dates.

One way to do this would be to assign the birth a sort date of 11 Jan 1903, to assign the death a sort date of 12 Jan 1903, and to assign the burial a sort date of 13 Jan 1903. These are fake dates and strictly speaking they are not correct, but they don’t print anywhere and they do the job.

Another way to accomplish the same thing is to assign the birth a sort date of 12 Jan 1903-1, to assign the death a sort date of 12 Jan 1903-2, and to assign the burial a sort date of 12 Jan 1903-3.

By default, RM assigns all facts a sort date that is equal to the main fact date and without using any dash suffixes. You can override the sort dates as needed. After establishing a main fact date and a sort date, you can change the main fact date. The expectation is that if you change the main fact date that the sort date will be changed to match, just like the sort date is is set to match when the fact date is first set. But in RM8, the behavior does not meet this expectation in all cases. It does in some case, but not all cases.

8

Perfect example. I have a few still Norns in my family and didn’t quite understand how to keep the order of facts for that person.

Does the sort date with a suffix have issues in RM7?

9

Sort dates have been supported in RM for a long time. They are supported in RM7, and the sort dates in RM7 transfer to RM8 just fine. I would emphasize that sort dates don’t have to uses the dashes. You can use fake dates instead. But it seems more logical to me to use real dates with the dashes.