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

[albertemmerich]

in our German group we have a discussion about the DATE payloads with BEF and AFT.
GEDCOM 5.5.1 defined:
AFT = Event happened after the given date.
BEF = Event happened before the given date.
This is interpreted by most users as the given date not be included.

Now GEDCOM 7.0 has modified the definition to:
BEF x = Exact date unknown, but no later than x.
This includes x.

Example:
GEDCOM 5.5.1
2 DATE BEF 1899
was interpreted as on any date up to 31 DEC 1898, but not on 1 JAN 1899 or later.
GEDCOM 7.0
2 DATE BEF 1899
is defined to be: on any date up to 31 DEC 1899 (included), and not on 1 JAN 1900 or later

How to handle this when converting GEDCOM 5.5.1 to GEDCOM 7.0 ? To have the same interpretation in GEDCOM 7, we have to write in GEDCOM 7.0:
2 DATE BEF 1898
decreasing the year by 1??

If one application does that, another does not, "same" data are represented in GEDCOM 7.0 in different ways.

Questions:

1. How should any conversion 5.5.1 to 7.0 handle this?
2. Is there any recommendation, how an application should show the data to the user?

For 2. we started to discuss using "<" for "BEF" from GEDCOM 5.5.1; and "<=" for "BEF" from GEDCOM 7.0 ....

Albert (Emmerich)

[dthaler]

Example: GEDCOM 5.5.1 2 DATE BEF 1899 was interpreted as on any date up to 31 DEC 1898, but not on 1 JAN 1899 or later.

My view (and my implementation) is that such an interpretation is not safe.
I've seen many examples of gedcom files that use "BEF 1899" when there is some event (month and day unknown) in 1899 at which the specified event was known to occur before. For example, if a land sale occurred in 1899 (month and day unknown) in which both the husband and the wife signed as grantors, then the marriage was entered as "BEF 1899". However in reality the marriage could have occurred in 1899, earlier in the year than the land sale. Hence it is only safe to interpret BEF as including the date when the month+day is not specified. Another way to interpret it is conservatively that "BEF 1899" is equivalent to "BEF 31 DEC 1899" (as opposed to equivalent to "BEF 1 JAN 1899").

[kiwi3685]

This change is pointless. It will never solve the problems of mis-use or mis-interpretation. It's more likely to make it worse.
You seem to forget that 99% (at least) of GEDCOM users will never read the "rules" let alone understand them.
All this change achieves is further complexity to very simple before / after terminology.

If you need to add further clarification to a BEF or AFT date just add a note.

[brezelman]

As a user, I always interpret BEF and AFT as including dates. Since these specifications cannot be approximate (cannot be combined with ABT/CAL/EST), they are usually specified as a conclusion based on the date of another event. As a user, I then use the exact date of the original event as the BEF or AFT to indicate the appropriate dependency. I can't imagine that the majority of users would then always add or subtract one to indicate the dependent date exclusively, nor would I hope that the software would do that. I would thus agree with @dthaler that the interpretation of the German GEDCOM group is probably not what is present in the majority of existing GEDCOM files and that the definition now established is the more reasonable one.

[Norwegian-Sardines]

I’ve alway used BEF/AFT to not include the date provided. Maybe it is a language use or some custom in a location, but BEF/AFT has never been inclusive of the date, particularly if in the future a TIME is included in the use of a DATE. This is particularly important when building a time line of events.

Saying the following makes no sense to me: “ that the definition now established is the more reasonable one.”. NO, It muddies the water more.

Like so many times in GEDCOM the designers try to not make a stand as to the meaning or definition of a word or tag, and leave it up to the user/application designer to decide the use. This attitude causes interfacing between two programs impossible when the program’s come up with their own interpretation. Interfacing is why GEDCOM is valuable, and not being precise in a definition defeats that value.

The definition should have been made more precise, for example:
Exact date unknown, but no later than x. Including x
Or
Exact date unknown, but no later than x. Excluding x.

I would thus agree with @dthaler that the interpretation of the German GEDCOM group is probably not what is present in the majority of existing GEDCOM files and that the definition now established is the more reasonable one.

Without surveying all applications I would not make this assumption.

Some software makes no designation of difference between FROM/TO and BET/AND. There is a difference and it messes with interpretation of the user base.

[Norwegian-Sardines]

Example: GEDCOM 5.5.1 2 DATE BEF 1899 was interpreted as on any date up to 31 DEC 1898, but not on 1 JAN 1899 or later.

My view (and my implementation) is that such an interpretation is not safe. I've seen many examples of gedcom files that use "BEF 1899" when there is some event (month and day unknown) in 1899 at which the specified event was known to occur before. For example, if a land sale occurred in 1899 (month and day unknown) in which both the husband and the wife signed as grantors, then the marriage was entered as "BEF 1899". However in reality the marriage could have occurred in 1899, earlier in the year than the land sale. Hence it is only safe to interpret BEF as including the date when the month+day is not specified. Another way to interpret it is conservatively that "BEF 1899" is equivalent to "BEF 31 DEC 1899" (as opposed to equivalent to "BEF 1 JAN 1899").

Not all “BEF” or “AFT” dates are only a year. If the date-value is always interpreted to be “inclusive” of the date-value then when the date-value is precise we can have a problem.

When creating a time line of events imprecise dates must be given a “sort value” and as you describe “BEF 1899” would logically have “BEF 1 JAN 1899” so than a date of “1 JAN 1899” sorts after it.

Therefore, using a year only example seams to make sense, when more precise dates are use, including the date-value in a “BEF” is not correct.

[Norwegian-Sardines]

This change is pointless. It will never solve the problems of mis-use or mis-interpretation. It's more likely to make it worse. You seem to forget that 99% (at least) of GEDCOM users will never read the "rules" let alone understand them. All this change achieves is further complexity to very simple before / after terminology.

If you need to add further clarification to a BEF or AFT date just add a note.

Many of the developers of software have not even understood the “rules”.

If you need additional clarification of the BEF date use the DATE.PHRASE

2 MARR
2 DATE BEF 1899
3 PHRASE Before the couple purchased the land, exact date unknown.