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/
