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 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.) 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. 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.) * 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. * 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?) * How does your module record the difference between "2000", "JAN 2000" and "1 JAN 2000"? * 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. Eugene
