Event Date sort order variation in 6.0

In Gramps AIO64-5.2.4-r1 (Win 11), Event Dates sort correctly like this in Person Events view:

Event [1]: from 1962 to 1988
Event [2]: 1988
Event [3]: from 1988 to 1990

However, in AIO64-6.0.0-1, the exact same events incorrectly sort like this in both Person Events view and in the Events Gramplet:

Event [1]: from 1962 to 1988
Event [3]: from 1988 to 1990
Event [2]: 1988

Is this a bug or just a setting issue?

I would guess that 1988, and “from 1988 to…” actually tie, and randomly one is first.

1 Like

I don’t think it is random. 6.0 consistently gives the wrong sort order with any similar date sequences. 5.4 always gives the correct sort order.

Does it make sense to add a tie-breaker to the sort? Where Date Quality is the the higher? i.e., exact dates rate higher than approximations?

Both “1988” and “from 1988 to 1990” have an integer sort value of 2447162. The actual order is probably determined by the order in which they are retrieved from the database.

Maybe we could change the sort value of a range or span to the mid-point? I’m sure that this has been discussed before.

1 Like

I would think that if they are using a “regular” date, it should be discrete and sort as @david1’s first example. 1988, and “from 1988 to…” should not tie as the later clearly implies a year beyond 1888.

I don’t think quality should be the deal breaker, it should be the span of time. Just as 1888 comes before May 1888, which comes before 07 May 1888, simply because the less precise the date, the earlier it can start.


Also, as a complete aside and newbie question, searching Date in the wiki takes me to Mixed Dates which redirects to Dual Dated which doesn’t seem to be a valid format anymore and the parent page is a stub, when what I really want is the 6.0 Manual Date Section.

Can you only search the Manual? How do we clean results up? Is there “seo” for results? Is there a process or training to be able to edit the wiki? Guidelines, etiquette, etc.?

1 Like

The way to search only the manual; AND only 1 version of the manual; AND only 1 language of the manual is:
download the ofline PDF of the most current version in your language to search.

I think if the integer values are indeed equal, then adding 1 to the integer value of any ranged date would give the correct sort order.

I don’t think we need to sort on a single integer, but could sort on (start_date_val, span_range_val) (where span_range_val would be 0 for no range) and then all of the dates would sort as expected, shorter spans coming before longer ones.

Should “between 1900 and 1910” sort before or after “1901”? At the moment it sorts before, but it is more likely that the event happens after “1901”.

Unless you have made a typo I would say the sort order is correct with
1901 coming after the start date of 1900.
phil

1 Like

When this was discussed previously, the following order was suggested:

  • 1900
  • 1901
  • between 1900 and 1910

The event “between 1900 and 1910” most likely, but not necessarily, happened after 1901.

I disagree that it should sort after. Just because there are 10 years, you can’t ascribe random probability to an event like this, and more importantly some events are not chronologically contingent. Yes, you can’t have a death before a marriage, but what if you had a newspaper event and a retirement event. Knowing that the newspaper reported he attended the wedding of a friend in 1901 has no impact on the probability of when his retirement occurred.

Also, what about those that use a range event for recurring events? or use a span event as inclusive?

In this case, we have two concrete facts. It could be as early as 1900 or as late as 1910. I contend that the earliest date should sort accordingly:

  • 1900
  • between 1900 and 1910
  • 1901
1 Like

This was also one of the opinions in the earlier discussion. We are repeating ourselves here.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.