TOPIC:

"Franz, your point was that using the known day of baptism where the day of birth is not known, is not serious genealogy"

I can not see where I said this!

I said using a christening date instead of the birth date in reports is not serious.

But I misunderstood the prevous contributions, where only the selection of results should be done by christening dates, which is not possible at the moment.

hermann wrote:

@drblam

Thus, entering the birth date as "BEF 1 JAN 1900" excludes the boundary case where birth and baptism happened on the SAME DAY

I'm not sure if you are right. GEDCOM 5.5.1 is not precise. If you say "BEF 1900" then the meaning of "1900" is "BET 1 JAN 1900 and 31 DEC 1900", so you might be right that "BEF 1900" could be "BEF 1 JAN 1900", i.e. a date in 1899 or before, but maybe you be wrong because in GEDCOM 7 the standard says "BEF" = "Exact date unknown, but no later than x". For me, that is more precise, so "BEF 1 JAN 1900" means "Exact date unknown, but no later than 1 JAN 1900", this includes the 1st of January.

So if you are right with "excludes the boundary" then you are only right with GEDCOM 5.5.1 and you are wrong with GEDCOM 7. I prefer already now to include the boundary to be right for the future.

This is interesting. Until now, I didn't know that GEDCOM 7 specifies BEF as you described. I indeed interpreted it for GEDCOM 5.x as "before", so this a new way of looking at it. I'll have to reconsider the use of these calculated assumptions and will have to start reading the GEDCOM 7 specs.

Thank you for this.

Edit: It possible will become necessary then, to change the translations as soon as webtrees becomes fully GEDCOM 7 compatible because the normal readers/users mostly will not be aware of the difference in meaning.

Franz Frese wrote:

"Franz, your point was that using the known day of baptism where the day of birth is not known, is not serious genealogy"

I can not see where I said this!

I said using a christening date instead of the birth date in reports is not serious.

But I misunderstood the prevous contributions, where only the selection of results should be done by christening dates, which is not possible at the moment.

Well, then it seems I misunderstood your statement also! Good that we spoke about it. ;-)

hermann wrote:

@drblam

Thus, entering the birth date as "BEF 1 JAN 1900" excludes the boundary case where birth and baptism happened on the SAME DAY

I'm not sure if you are right. GEDCOM 5.5.1 is not precise. If you say "BEF 1900" then the meaning of "1900" is "BET 1 JAN 1900 and 31 DEC 1900", so you might be right that "BEF 1900" could be "BEF 1 JAN 1900", i.e. a date in 1899 or before, but maybe you be wrong because in GEDCOM 7 the standard says "BEF" = "Exact date unknown, but no later than x". For me, that is more precise, so "BEF 1 JAN 1900" means "Exact date unknown, but no later than 1 JAN 1900", this includes the 1st of January.

So if you are right with "excludes the boundary" then you are only right with GEDCOM 5.5.1 and you are wrong with GEDCOM 7. I prefer already now to include the boundary to be right for the future.

@Hermann, thanks for the information about GEDCOM 7, which I find rather disturbing... In essence, (the anonymous) "they" has decided to change the definition of the word "before" (written as BEF) from the standard mathematical operator "<" to the operator "<=". Why not change the abbreviation to match their intent? In some programming languages we use LEQ, for example.

This idea of taking some vague concepts and making them "precise" in arbitrary way can create bizarre situations. In this case, if I understand what GEDCOM 7 is *actually saying* (as opposed to what they intended), then:

the date "31 DEC 1900" must satisfy the condition "BEF 1900" because:

"1900" actually means "BET 1 JAN 1900 AND 31 DEC 1900", BEF includes strict equality, and thus

"BEF 1900" means "no later than 31 DEC 1900"

I find this result both unintuitive and unhelpful. But at least in this case, a request to "show me all individuals born before 1900" would induce a Type 1 error (false positive) by including people who should have been filtered out.