I like that idea. I prefer to enter time spans (or was it ranges…I also find those two easy to mix up…) for events even if dates are very uncertain.
“Before” or “after” is kind of vague. A 20 year old person I “lost” at 1800 is “dead after 1800” but might still be alive 60 years later. A child that was baptisted 1750-02-03 where I don’t know the exact birth date can be registered as “born before” (actually “before or equal” would be better") but in that case probably not 60 years before… So I prefer to enter an interval instead of those. (I do use “about” although that’s also vague. There I use my own rule that it means ± a few years if only year is specified and ± a few days for a complete date)
Lets say all I know about person AA is from a birt record from year 1700 saying “Blacksmith AAs son BB in xyz”. I estimate that AA was between 20-50 years at that point and died at age 85 or younger. As I said I don’t like “before” or “after”, so thats birth = estimated(between(1650, 1680)) and death = estimated(between(1700, 1765)). Having death = between(1700, estimated(1765)) would make it obvious that he was known to be alive in 1700. (Then it would be nice to also have some max age value for fuzzy dates in reports so the person is not reported to have died “between 20 and 115 years” age.)
That sounds like 3 events with only 2 that are actually known: an unknown birth, a known baptism and a known legal (or church) registration filing of a pedigree parentage.
There are potentially three separate events, if you choose to record all of them as such: birth, baptism, and birth registration. Personally, I just record birth and baptism events.
Regardless of whether you record the baptism or birth registration as events, those records can be used as sources to cite for the birth event (assuming they mention the date of birth).
Yes, when citing the birth registration as evidence of the birth, for the citation date I would use the date of the registration (hopefully something more specific than 2nd quarter.
That is the general rule I follow: the citation date is the date of whatever record I am citing (newspaper article, birth/death certificate, etc.) and not necessarily the date of the event that is being described.
I use ‘about’, ‘before’ and ‘range’ often when a date is not specific. I don’t see the need to change the terminology. To me, using ‘about’ means ‘estimated’ or ‘around’ but needs to be close to a reasonably calculated date. I use it a birth date is not known but the baptised date is. Or an age is recorded on a census item where the exact year of birth is likely +/- 1 year.
I know this is slightly dodgy seeing how often ages are incorrect on Census forms but, generally, I consider it better than leaving the date blank. I have no issue with the current terms (‘about’ etc).
How do you do it if an event is a span has a known spesific start date, but the event is still going on like Education or Occupation or Residence? “After” is not correct from what I understand from here, and Span doesnt let you only put in one date?
Ah, based on what people wrote I thought that “After” on an event ment it could have started at any point after the date and not started at that date and continuing after that?
This how I use it. I consider there are two types of events: instantaneous (no duration) and spanning (with a duration).
Instantaneous events have a single date which may be known (on …) or approximative (before, after, between).
Spanning events are badly described in Gramps IMHO because they are encoded as “from … to …” with exact dates while both bounds may not be known accurately. This is a consequence of a design decision: there is room for only two temporal references in a Date record. To cope with approximate spanning date, the record should have contained four temporal references, doubling the footprint. This is clearly not acceptable in terms of storage resources.
Since a Date can also by “reduced” to a string when input is not compliant with a calendar, you can enter ‘Present’. I have not tested it with span date to see if validity requires that both dates have the same type/calendar, but I’m rather confident this is possible.
It would be better if you could set it to span, but instead of one of the dates, could enter unknown or current/present but you cant I dont think, at keast without it changing to just text. Or just span with a single date, and the Gramps just show “from X” and dont mention to or a second date.
So I am guessing people do different things in this situation.
I use “from <date> to present” for these open-ended spans.
The error/alert setting only shows within Gramps. Any reports generated will display as normal.
The only issue is issues is that the entry in Gramps remains text and does not get stored as a valid date and as such, you may need to hand enter the date portion to conform to the date display option.
As a purely text entry, date filtering may be an issue.
Present doesn’t mean anything for me. Present according to what time reference? When do you write the event? Is this still valid when you reopen your base?
Any “present” placeholder seems fragile & dangerous.
You are basically representing anything with the “present” as verified on the date the data is distributed. I suppose that if the “present” placeholder was left in place and the footer has the publication date, it implies a laissez-faire quality to the data. But if the placeholder substitutes with a hard date (particularly in a document with source references elsewhere), it implies the dates were validated by the author.
So, unless you intend to manually validate each “present” notation each time you publish, this seems like a risky approach.
Note that the word “today” is evaluated during data entry and that day’s date is substituted instead when you commit. So any process that uses “today” in another manner could confuse that usage.
Could also just be some other way or word for that gramps more clearly shows it is a span, but the end date isnt known or havent happened yet.
(could also be done for start date maybe)
It doesnt have to be the word spesific word “present” or anything, it was just what Dave said, I dont really care how its done just better than currently is.
I think script that auto updates the date is a really poor choice personally as that is also wrong, because the end date is NOT today, its either unknown or not happened yet.
