Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Lars Kr.Lundin <gramps@lk...>  20021225 22:32:15

Thanks for coming up with these ideas. I think the idea of separating the date and the calendar and to associate the date validation with the calendar is very good. Allow me to elaborate on the internal daterepresentation. GEDCOMP (my genealogy database) handles dates internally using interval arithmetic (a concept from numerical analysis). Basically, something like a point in time is represented not as a real number but as an interval (ie. a lower and an upper bound) in which the actual value is guaranteed to lie. Pretty much anything that one can do to a real number can be defined to also apply to such an interval. Interval arithmetic is useful for handling not only inaccurate representation of real numbers (like in a computer) but also for f.ex. inexact dateinformation in genealogy. I would expect an intervalarithmetic library with python bindings to exist. GEDCOM DATEs like 1712 DEC 2002 BET 1800 AND 1850 25 DEC 2002 are all intervals (the last has equal lower and upper bound). AFT 1900 is also an interval  an openended one (with infinity as upper bound). When an event described by an AFTdate is known to have happened (like someones birth and notably not a living persons death) the interval can be upperbounded with some date (like todays date or the creation date of the GEDCOM). Trying to entirely avoid openended intervals in this way could however prove too restrictive. In genealogy it is useful to be able to handle inexact interval bounds. Consider a person X who died in 1770 with a son approximately 30 years old. The upper bound of X's death date is 31 DEC 1770 whereas the lower bound is ABT 1740. For the DATE ABT 1780 both the lower (1 JAN 1780) and upper (31 DEC 1780) bound is inexact. One could argue that the timerange (GEDCOM FROMTO construction) really should be described by two intervals, the first marking the start date of the timerange, the second marking the end. I agree that it is sufficient to instead mark the interval as a range. Consider f.ex. person Y who lived in London from 1066 to ABT 1111. The lower bound (year 1066) is really an interval (with a point in time between 1 JAN 1066 and 31 DEC 1066), but all we can say for sure is that Y lived in London from 31 DEC 1066. So the upper bound of the starting interval and the lower bound of the ending interval that form the range are really all that are useful. So I think the best way to represent a piece of dateinformation internally is by A) its calendar B) its lower bound date (always yearmonthday) with a ternary indicator with the possible values: exact, about and (minus) infinity (for BEFore) C) its upper bound date (always yearmonthday) with a ternary indicator with the possible values: exact, about and infinity (for AFTer) D) a range flag for when the state is true throughout the interval, ie. to distinguish between f.ex. 1 NAME Alive /Today/ 1 DEAT 2 DATE AFT 25 DEC 2002 and 1 NAME Dead /Today/ 1 DEAT 2 DATE FROM 25 DEC 2002 I have just reread the Date object description and now I wonder if there is any difference at all between 1)4) and the above A)D). If 1)4) describes the same as A)D) then at least I hope that others than myself have gotten a better understanding of the internal date representation in GRAMPS. > Regional differences can be handled by different calendars. For > example, if Region1 and Region2 had two different switch points > between the Julian and Gregorian calenadars, the could be represented > by two different calendars, such as 'Julian (Region1)' or 'Julian > (Region2)'. Very nice. Thank you, Lars Lundin.  GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ 