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

Hi Eugene

On Thu, 2011-09-15 at 12:45 +0200, Eugene van der Pijll wrote:
> Ron Savage schreef:
> > o The previous author of Gedcom::Date added some Dutch words to his
> > code, so I added the Dutch month names.
> 
> I would have preferred the title of "other author"; I'm still keeping

Do you mean changing this text "Thanx to Eugene van der Pijll, the
author of the Gedcom::Date::* modules." to add 'other', or something
else? I'm quite happy to change what the comments say.

> open the option of continuing to work on Gedcom::Date later. (In fact,
> I've been working on a script to validate GEDCOM files, and that has
> given me a bit of insiration about future improvements.)

OK.

> About the Dutch names: Gedcom::Date only uses these for output.
> When parsing GEDCOM strings, only the restricted set of month
> abbreviations in the GEDCOM standard are accepted.

OK - I'll cut the Dutch words out. But as you can see from other emails,
and your own experience, calendar/language support is complex.

> Some remarks about DT::F::Gedcom:
> 
> * It doesn't follow the semantics for DateTime::Format::* modules:
>   parse_datetime() doesn't return a DateTime object, and it doesn't have
>   a format_datetime() function. This is understandable, because a GEDCOM
>   date string does not always correspond to an exact date, but I wonder
>   if it should be in this namespace.
> 
>   (This is the reason that Gedcom::Date is not in the DateTime
>   namespace, even though it returns DateTime objects.)

I feel this is a difficult decision, for the reasons you specify.

I think the basic problem is that the GEDCOM doc was not designed to fit
into the DateTime namespace, but the concept of parsing dates does,
especially given I decided to return DateTime objects.

It would (also) make sense to call it Genealogy::Gedcom::Date.

Anyone care to comment either way? Renaming it would stop a waste of
energy arguing about this.
 
> * Not accepting years < 1000 is a bad thing, certainly if you accept
>   dates in the French calender. Single digit years are very common in
>   that calendar. DateTime can handle 3-digit years, and even BC years; I
>   would expect the same from any DT parser module.

As I said in another reply, I pre-process the candidate date, and then
pass it to DateTime::Format::Natural, but the latter does not always
accept years < 1000.

> * What is the value of the "one_ambiguous" flag if it is set by "1 JAN
>   2000" (especially when "1/1/2000" isn't ambiguous either, and
>   "1/2/2000" is not * allowed by the GEDCOM standard?)

I overlooked that case.

> * How does your module record the difference between "2000", "JAN 2000"
>   and "1 JAN 2000"?

It doesn't.

Is it worth extending the code to return info about those distinctions?

> * What is the benefit of using this module over Gedcom::Date? Or do you
>   have future plans that cannot be done with Gedcom::Date? Not that I
>   mind a bit of competition, of course.

It isn't necessarily superior.

It does aim to return more information per date, which is very important
to me.

Also, it helps me exercise my coding skills.

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622