Hi Eugene
On Tue, 2011-09-20 at 20:40 +0200, Eugene van der Pijll wrote:
> 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.
There's always the problem of getting people to stick to any 'standard'.
> > 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.
Seems to me we're talking about 2 different things:
o What researchers record, which is exported as a GEDCOM date.
o What syntax a parser provides to give programmers access to the date
data.
The more latitude the former have, the more complexity the latter needs.
> > (*) 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
>
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
