On Tue, Sep 20, 2011 at 11:19:32AM +0100, Stephen Pickles wrote:
> These are important questions.
[ Good observations and points. ]
> A couple of years ago, I wrote a little tool to extract all exact
> dates of birth, marriage and death events from a GEDCOM file, and
> write them out as a calendar file (ical format, RFC 2445). I was using
> Paul Johnson's Gedcom package from CPAN. I started out using
> Date::Manip to parse dates (partly because the Gedcom package was
> already using it), but I ended up having to write my own parser. The
> problem was that Date::Manip's parser would fabricate days ("JAN 2000"
> would come back as "1 JAN 2000"). Paul Johnson's date normalisation
> routine suffered from the same problem, because it too relied on
> Date::Manip. A pity, because date normalisation would be very helpful
> when you're comparing information about an event from two GEDCOM
> files.
I'm afraid I've not been keeping up with the messages here recently. My
excuse it that I got behind at YAPC and have been really busy with work since
then. But be that as it may, let me comment on this particular aspect.
What Stephen says about Gedcom.pm is all true; I really punted on the date
handling. There are two reasons for that:
1. It's hard. I didn't want to write yet another date handling package.
Date::Manip is overkill in almost all respects and yet, as Stephen notes,
it is still insufficient for genealogical use. And I just didn't have the
heart to dive into its own code.
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.
And then there's the question of what are you going to do with the
dates anyway? Full, complete dates are clear(*), but what about all
the other possibilities, either allowed by the GEDCOM spec or not.
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".
So I thought to leave dates as basically free-form fields, with the
option to use Date::Manip to normalise them as far as possible, if
required.
(*) 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.
> Thanks for starting an unusually interesting discussion.
Agreed.
--
Paul Johnson - p...@pjcj.net
http://www.pjcj.net
