Dates in GRAMPS apply both to instant and lengthy events. To make things clearer, “life” has a duration while “birth” or “death”, at least on first approximation, are instantaneous. A duration can be expressed in a variety of ways but ends up with two dates: start and end.
GRAMPS makes a distinction between “spot dates” and “interval” through two classes: Date and Span.
Generally dates are not known accurately. We are offered “about”, “before”, “after” and “range” (wording in the documentation) for this when a date is nor “regular”. The Gramps Type: menu offers extra choice “span” which is not logically related to accuracy. This “span” item tags in fact a duration. Note that the distinction between “range” and “span” is not obvious for a newbie (and even for a regular user) and this is made worse in the translations. “span” choice will enable use of Span class.
The Date class handles correctly accuracy as it contains two fields to record the interval limits
But it is also used to store “span” intervals. This means that the two fields are populated with the interval limits and user can no longer provide accuracy information on the bounds. This would require four fields instead of two.
Take for example a residency event. We may know it started “around 1750” and ended “after 1780”. This can’t be represented in the current implementation unless the event is split in two: residency start and residency end events. This is not user-friendly because all the properties are shared by these events which are logically a single one.
Would it make sense to change the Date class to handle more thoroughly time intervals? Is this a desirable feature?
Is doubling the space needed for a date acceptable?
I am aware this would have a huge compatibility impact on existing DBs but I am ready to experiment.
I’m not sure how much date handling is regulated by GEDCOM and how much Gramps can change. Gramps still needs to be able to import/export GEDCOM without loosing information. This limits new features a lot unfortunately.
In general I’d avoid spliting an event into start and end, because data duplication, but some people might prefer doing that.
I tend to add dates instead of time spans, beacause they are easier to handle. In my DB occupation or residence events usually just use the date of the entry where I found the information and not a time span.
Gramps already handles dates both as ambiguous and as a span of time.
As the specific date: 4 July 1776
and as ambiguous dates:
about 4 July 1776, or about July 1776, or about 1776
and the same dates using before and after as the modifiers.
Additionally you can use between <date> and <date> to indicate an unknown specific date having occurred sometime between the dates specified. This being different than using from <date> to <date> to indicate a span of time.
All of these date options can be entered directly into the date field or you can use the Date Editor to construct the entry.
Additionally in Preferences’ Dates tab you can define what “about”, “before”, and “after” mean. These definitions come into play when calculating ages for an event and in filtering. The defaults are all 50 years. What this means is in a filter to find people born in 1900, a person with a birth date “about 1950” or “about 1850” will also return as valid for the filter. The same concept applies if the filter parameter is “after 1900”. Based upon the 50 year default, events with dates between 1900 and 1950 will return as valid. This is why it is always best to filter “between <date> and <date>”
Thanks @DaveSch, I already know all this. My point is the inability to express inaccuracy on a span “date”. This is in fact an interval of time with a beginning and an end. Obviously an interval of time is not a point in time. That a point in time may be exact, approximate, before, after or between does not change the fact that presently a point and an interval are represented within the same data structure. This implies that the interval is always considered exact (because there are only two date slots in the object) which is rarely the case in genealogy.
Therefore you can’t translate your uncertainty on the interval bounds. Both bounds may have different accuracy. See my example about a residency event.
I think subevents could resolve, may be, these dates issues.
It could be done with something like that:
event: Residence from date1 to date3
subevent Residence 1: about date1
subevent Residence 2: date2
subevent Residence 3: around date3
It would add precision to the main event, all knowledge we have of it. And for the gedcom, it could inherit date from main event and sources, attributes… from subevents. Maybe gedcom creation could generate and add a note automaticaly to the event to augment it, translating the subevents meaning
Gramps still needs to be able to import/export GEDCOM without loosing information.
I thought GEDCOM exports were already lossy.
I think a very strong argument can be made the concern over GEDCOM compatability and the GEDCOM oriented mindset have held back the evolution of Genealogical software for two decades now.
Yes fully agree with that. Also many forum discussions about new fetaures died because there was no useful way to store new data in existing GEDCOM structures. Sometimes there were workarounds using the existing structures, but the usability was terrible.
Couldnt it be done that a lot of the things GEDCOM dont support directly, is converted to notes on GEDCOM export in some way? Instead of just not include them.
I’ve been using Gramps for 6 years, with original research (not copied) on 12,000 people.
I have never encountered a situation where this was a practical issue. Normally, just representing the end dates with suitable precision (gramps is happy to omit day-of-month and month-of-year) seems to handle most realistic use cases.
Representing lack of precision in a precise way (!!) is not needed strongly enough to justify the complexity of the code change and maintenance it would need.
I’m on the 6000 range. But many people lack records so for them it’s guess work. Based on other records I can have something like “period from after 1750” to before 1780 in the majority of cases. It is part of my way to tag work-to-be-done.
But sometimes such a duration event may be associated to recorded deeds. I should probably split into a begin event with the “stamped” record and an end event with again another record.
You’re probably right in your advice with truncated dates. Perhaps text dates like “Spring 1750” to “Autumn 1780” would be the ad hoc mention.