Misleading date range labels? (Before, After, Between)

[ztlxltl]

The first 7 posts were split from a FamilyTreeView thread to this new topic to discuss potentially misleading labels of the “Before”, “After” and “Between” date modifiers:

@ztlxltl

I just checked the date GEDCOM specification and “AFT” (“After” in Gramps) doesn’t mean “after specified date” but “no earlier than x”, i.e. “specified date or after specified date”. So ≥ is correct and > is not.

I have to admit that from my point of view this is a big issue in the Gramps UI. Although GEDCOM’s “AFT” suggests the meaning “after”, using that word for the label in the UI (because it is similar to the three letter code used in the GEDCOM file format) over a label that actually matches the correct meaning, is a big issue that should be fixed in a Gramps update. The same significant problem exists for “before” and “between … and …”, but not for “from” (= “beginning on x”) and “to” (= “ending on x”).

In the latest version of FamilyTreeView (v0.1.109), I added a feature that has been requested several times (here and here by @Urchello): a way to display dates compactly. The two images below show dates and their compact representation. Please keep in mind that the representation is just a first attempt/draft.

[Unrelated parts of the original post have been removed.]

[emyoulation]

Instead of < and > , how about “≤” ≤ and “≥” ≥ ?

And use ↔ ↔ for ranges and spans?

[ztlxltl]

@emyoulation

how about “≤” ≤ and “≥” ≥ ?

You are correct. I just checked the date GEDCOM specification and “AFT” (“After” in Gramps) doesn’t mean “after specified date” but “no earlier than x”, i.e. “specified date or after specified date”. So ≥ is correct and > is not.

I have to admit that from my point of view this is a big issue in the Gramps UI. Although GEDCOM’s “AFT” suggests the meaning “after”, using that word for the label in the UI (because it is similar to the three letter code used in the GEDCOM file format) over a label that actually matches the correct meaning, is a big issue that should be fixed in a Gramps update. The same significant problem exists for “before” and “between … and …”, but not for “from” (= “beginning on x”) and “to” (= “ending on x”).
I think I (and probably many others) have entered dozens (maybe hundreds) of after/before/between dates incorrectly because of this mislabeling!

[emyoulation]

well, it is more than that.

I originally believed that the new “To 15 Mar 2025” and “From” were open-ended: “-∞ to (and include) 15 Mar 2025” and “from (and include) 15 Mar 2025 to ∞”. But they (like “Before” and “After”) are limited and use the Limits preferences.

@Nick-Hall says “To” and “From” use identical logic to the “Before” and “After”

I do not see the point of adding another 2 types that are aliases for 2 existing limited span types. Adding complications only made sense when adding open-ended spans that did NOT have limits.

[ztlxltl]

While I agree that to and from should describe the time to negative/positive infinity. It definitely makes sense to have a distinction between them and “before”/“after”/“between”. “before”/“after”/“between” describe ranges (some day before/after/between the given date(s)), while “from”/“to”/“from … to …” describe a span (all days before/after/between the given date(s)), so they definitely have their right to exist.

I think it would make sense to change “after x” to “x or later” and “before x” to “x or earlier” (or something similar). A similar change needs to be made for “between”, but I think there is no better wording than adding “, including/inclusive” to the current “between x and y”.

Do you know any related discussion here in the forum or in the bug tracker about this misleading labeling?

[emyoulation]

@ztlxltl

Do you know any related discussion here in the forum or in the bug tracker about this misleading labeling?

I agree mathematical accuracy is important.

The thread noted in my previous has the only discussion of which I am aware. And it has links to the GitHub PR and related Wiki section.

[ztlxltl]

@emyoulation

The thread noted in my previous has the only discussion of which I am aware.

Since the discussion you mentioned above is about “from” and “to”, not the misleading “after”/“before”/“between”:
Do you think it would make sense to move this discussion to a new thread/topic? That way other users might be able to find this discussion more easily and we might get more opinions on this topic.

[emyoulation]

@ztlxltl

Do you think it would make sense to move this discussion to a new thread/topic?

Moved. (Now for something completely different … to meet the 20 character requirement.)

[ztlxltl]

Now that this separate discussion has been untangled, I would love to get some feedback from others on the (in my opinion) misleading labels.

Since he discussed the “To” and “From” with @emyoulation before:
Perhaps @Nick-Hall would like to comment on this topic?

[stuck]

I would expect these terms to mean:
‘to’ and ‘from’ are inclusive and unbounded. Thus ‘to’ means less than or equal to dd/mm/yyyy, while ‘from’ means greater than or equal to dd/mm/yyyy.

‘before’ and ‘after’ are not inclusive and unbounded. Thus ‘before’ means less than dd/mm/yyyy , while ‘after’ means greater than dd/mm/yyyy.

‘between’ is inclusive but (obviously) bounded. Thus ‘between’ means greater than dd/mm/yyyy AND less than dd/mm/yyyy.

[ztlxltl]

It doesn’t seem that the original question for this discussion thread originates from an inconsistency in Gramps, but rather from a change made in the GEDCOM specification between versions 5.5.1 and 7.0.

Modified summary taken from here:

• GEDCOM 5.5.1 (PDF) defined:
  AFT = Event happened after the given date.
  BEF = Event happened before the given date.
  This is exclusive and uses the meaning of the words “after” and “before” so the UI matches the standard.

• GEDCOM 7.0 (PDF, HTML) has modified the definition to:
  AFT x = Exact date unknown, but no earlier than x.
  BEF x = Exact date unknown, but no later than x.
  This is inclusive.

• FROM and TO are inclusive in both versions and match the meaning of the words and therfore the UI.

It doesn’t make much sense that Gramps will change its GUI or internal date handling/comparison when switching to GEDCOM 7.0. These changes will likely only need to be considered when importing or exporting GEDCOM files.
Since @DavidMStraub is working on supporting GEDCOM 7.0, he may be able to provide insights into which parts of Gramps will need to adapt to this change and how he is addressing it in his implementation.

There is an “unanswered” discussion about this specific change in the GEDCOM repository:

DATE: problem with GEDCOM 7.x definition for BEF and AFT · FamilySearch GEDCOM...

[Nick-Hall]

@ztlxltl

Perhaps @Nick-Hall would like to comment on this topic?

@ztlxltl

It doesn’t make much sense that Gramps will change its GUI or internal date handling/comparison when switching to GEDCOM 7.0. These changes will likely only need to be considered when importing or exporting GEDCOM files.

I agree. Changing the current meanings is not a good idea and adding new “No earlier than” and “No later than” options would potentially be confusing.

The Gedcom 7.0 import/export should handle the necessary conversion.

[comeng]

Personally could not care less about GEDCOM import/export accuracy but I know a lot do. So I tweaked the datehandler program such that

< = before

> = after

>< = between and

Made a huge improvement to the GraphView display

phil

[emyoulation]

@comeng

So I tweaked the datehandler program

Is this tweak shared somewhere?

Regarding Dates

Intuitively, the To and From imply an (inclusive ≥ and ≤) endpoint and that the opposite endpoint limitation is either implied or will be made explicit.

My logic for this is:
when the From and To are combined in a single phrase (“from 22 Jan 1879 to 14 Feb 1879”), it is limited and inclusive Span.

Likewise, the Before and After are complementary (exclusive < and >) endpoints without implicit limits. When complementary endpoints are added (“between 14 Jun 1654 and Sep 1654”, aka “15 Jun 1654 - 31 Aug 1654” or “> 14 Jun 1654, < Sep 1654”), it becomes an exclusive and limited Range.

So this could translate into an interface update the Date Editor cleanly.

Instead of the one-endpoint dates always pre-filling into the Date fields, right-sided endpoints (To and Before) would pre-fill into the Second Date. The dimmed side of a limited one-sided term would pre-fill with a calculation of the preferences evaluation limit.

Converting betwixt open-ended From/After/To/Before and a FromTo/Between is just a matter of changing the Date Type pop-up menu selection. It would inherit (or refresh the pre-fill value) from the preferences.

Other GUI Changes

There could be feedback of the Preference approximation limits (About ±10 years) that is hotlinked to open the Preferences tab.

The Text Comment box could become a pop-up selector for parsing alternatives for ambiguous text. (Which remembers the last ambiguity resolution for repeating a resolution.) So the European or US date order parsing convention could be manually selected.

Or more ambitiously, an ambiguous Span/Range for a Vital Stat event could be split into 2 Regularly dated Events that share the same place and Citations. So a Birth event of ambiguous 1964-2007 could offer “between 1964 and 2007”, “born 1964, died 2007”, “born 1964, baptized 2007”, and “born 1964, christened 2007”. Marriage could likewise offer a “between” parsing or Event splits into Marriage and Divorce/Separated; or Marriage License and Marriage.

(Does the Left-Right ordering of Spans/Ranges differ for right-to-left writing languages?)

This Date Selection dialog still needs a hot link to spawn an undocked Calendar Gramplet so you can more easily determine references (like “Next Tuesday”) from a given date.

Or to have dual calendars inset in the dialog per feature request 13754 and discussion in PR2001

[emyoulation]

For completeness, @dsblank also proposed a calendar widget improved with decade scrolling buttons in the interface:

Built-in Calendar Gramplet

You can’t, unless you do a little bit more work. I like this very much: [image] Three arrows - decade controls Two arrows - year controls One arrow - month controls If this looks good to you all, I’ll make a PR for Gramps 6.1.

So the buttons are:
-10 -1 -1/12   +1/12 +1 +10