Paul Johnson schreef:
> 2. As Stephen also notes, I didn't feel that the GEDCOM specification's
> description of dates was sufficient anyway. So even if I, or someone
> else, were to fully implement it, I didn't think it would be a full
> solution.
There are several things in the GEDCOM specification that are definitely
missing: phrases like "FROM BEF 1820 TO ABT 1825" for example. It would
be interesting to develop a more complete GEDCOM-like date grammar.
> And then there's the question of what are you going to do with the
> dates anyway?
There's several things that a GEDCOM Date module (or a program) would
want to do with a date:
* Validate
* Date math / checking, such as "is date B more than 16 years after date
A?"
* Text output, e.g. for report writing ("ABT APR 1820" => "around April 1820").
All of these are still useful even with the more interesting GEDCOM date
formats.
For example, using my own module:
use Gedcom::Date;
my $birth = Gedcom::Date->parse("BET JUL 1820 AND JUL 1825");
my $marr = Gedcom::Date->parse("BEF 1834");
print "Too young at marriage\n"
if $birth->clone->add( years => 16 ) > $marr;
You really want to be able to write such a validation rule, without
having to treat all different GEDCOM date formats in your code
explicitly.
> Most tools would have no idea how to handle "Between May and July
> 1678", let alone something like "Easter Sunday in either 1783 or 1785".
That most tools can't handle the first date is no reason not to try to
accept it in your own scripts. The second date is not really expressable
in GEDCOM, except as a (unparsable) date phrase.
> (*) I say clear, but what about times and time zones, or calendar
> changes? And no doubt there are other complexities. Rarely is
> anything clear-cut in genealogy.
GEDCOM was originally designed as an output scheme for genealogical
conclusions. Calendar changes should have been handled by the
genealogist or the program that created a GEDCOM file; when a date has
been outputted to a GEDCOM, it refers to a definite date in a known
calendar (either explicitly by a @#D...@ escape, or implicitly to the
Gregorian calender).
Times are outside the scope of GEDCOM; the standard has defined no tags
for them.
So while times, time zones and calendar changes are problematical in
genealogy, they shouldn't be a problem when interpreting a valid GEDCOM
file.
Eugene
