Re: Announce: DateTime::Format::Gedcom V 1.00

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