Would it be usefull to have a "Snapshot" kind of DATE?

[mother10]

Maybe I am making things too difficult, but look at the following situation:

Suppose in a tree I have a Dad John, and his daughter: Mary. I knew nothing about John yet, until I found that marriage record. But now I found that source for Mary, getting married on an exact Date. In that source, for the first time John is mentioned as her dad, and said he is a farmer, living in Alkmaar.
That gives me an exact date for the marriage itself. But for John, it only tells me he his name, I can guess a bit about his age, and say he was a farmer on that marriage date of Mary. That does not mean he started being a farmer on that date, he already WAS a farmer before that marriage. And he probably still was a farmer after the marriage. So it does not tell me the day he started being a farmer, it was merely a snapshot from the, maybe very long period, he already was a farmer. So I can add the source of the marriage to Mary, proving she was married at that day and fill in the exact day of her marriage. But in fact I cannot use that same exact DATE as an exact Date for anything for John.

So when I turn it around, and I find a DATE for something in my tree, sometimes it is the exact date an event really happened, but sometimes it is not. In that second case for instance, I cannot use it to calculate how long John was a farmer. But I CAN use the marriage date to calculate how long Mary is married.

We do have ways of denoting DATE periods, so we can give a start and ending date. Or a start and ending date that are approximate.
But we have no way to define a "Snapshot" kind of Date. So a Date in the middle of a period of which we dont now the beginning nor the end yet. And I think a lot of records we find, have in fact snapshots Date's for people mentioned in there, but who are not the main characters the source is about.

Would it be helpfull if we had such a definition? Or am I creating problems where there are none.
For now I just add the dates for farmer and such as fixed dates, thats not the problem, but that feels wrong.

[tychonievich]

As you note, we have date productions for date ranges. Without such productions no particular beginning or end of range is implied.

Farmer on a day, and possibly on other days too:

1 OCCU Farmer
2 DATE 24 JUN 2024

Farmer starting out in that occupation on a particular day, with unknown duration in the career:

1 OCCU Farmer
2 DATE FROM 24 JUN 2024

Farmer for just one day:

1 OCCU Farmer
2 DATE FROM 24 JUN 2024 TO 24 JUN 2024

[mother10]

ok I understand, I use that kind of dates.

Thanks,
Tineke

[mother10]

Ah yes, that looks very understandable. Thanks!

[fisharebest]

In GEDCOM 5.5.1, SOUR.DATA.DATE is described as "Date when the entry was recorded in source document".

In GEDCOM 7.0, DATE is not defined.

Assuming the definition is unchanged, then this GEDCOM would indicate that 24 JUN 2024 was the date that the individual was recorded as having been a farmer - not the date at which he was a farmer.

[Norwegian-Sardines]

The definition of SOUR.DATA is a little confusing as it relates to a potential use for SOUR.DATA.DATE.

I see two descriptions of SOUR.DATA.

• p.62 "the relevant data from the source"
• p.74 "'SOUR.DATA` describes the content of the source."

SOUR.DATA.TEXT is defined as "A verbatim copy of any description contained within the source."

When we look at the descriptions "relevant data from the source" and "content of the source" these both seam to refer to the "data found in the source" and for a date within this definition we are most likely talking about the date or date range of the event or attribute. The definition and use of SOUR.DATA.TEXT follows this logic as well referring to the text data found in the source.

Therefore, even though I agree with @fisharebest about how I would use the SOUR.DATA.DATE payload (recording date), without a specific definition for the tag we can not assign a recording date to this payload!

In addition some applications may want to use this payload to indicate the date the data was retrieved from the the source. Which is an important Source_Citation element needed and missing from the equation. The retrieval date data could be more important than the recording date.

[webtrees-pesz]

In GEDCOM 5.5.1, SOUR.DATA.DATE is described as "Date when the entry was recorded in source document".

In GEDCOM 7.0, DATE is not defined.

Assuming the definition is unchanged, then this GEDCOM would indicate that 24 JUN 2024 was the date that the individual was recorded as having been a farmer - not the date at which he was a farmer.

Yes, that is correct. We don't know the time period in which the bride's father was a farmer. That's why I don't think it makes sense to give a date for the occupation, because the consequence would be several occupation entries, each with a date, if there are several mentions. I think it makes more sense to have one occupation entry and to refer to the relevant sources with their dates of recording.

[mother10]

@webtrees-pesz Yes that seems a good solution.

[mother10]

@fisharebest Maybe add the description back in version 7?