Skip Menu |

This queue is for tickets about the Date-Manip CPAN distribution.

Report information
The Basics
Id: 53099
Status: resolved
Priority: 0/
Queue: Date-Manip

People
Owner: Nobody in particular
Requestors: John [...] WashburnResearch.org
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 6.05
Fixed in: (no value)



Subject: ParseDate("April 1625") = 1925041600:00:00
Dear Mr. Beck: First I want to say I love Date::Manip. I found what may or may not be a problem. I have been using PERL to process some genealogical data. This means some dates are partial. The generic behavior of Date::Manip is to interpolate to the first of the month, interpolate to the first month of the year, and to interpolate to midnight. When I use a partial date of month and year such as, April 1625, Date::Manip parses this string as if the string were April 16, 25. I expected to get a parsed date of 1625040100:00:00 instead of 1925041600:00:00. I was surprised by this parsing, but I am not sure I can consider it a defect. I violated one of the design specs of Date::Manip by not providing a string which resolves to a particular date. distribution / perl / os informaiton Date::Manip: Date-Manip-6.05-EDfANj Perl: This is perl, v5.10.1 (*) built for i686-linux OS: Linux Washburn-Ubuntu 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009 i686 GNU/Linux this code #!/usr/bin/perl -w use strict; use Date::Manip; my @PartialDates = ( "apr. 17, 1625" ,"apr 17 1625" ,"April 17, 1625" ,"April 17, 25" ,"April 1625" ,"Apr 1625" ,"Apr. 1625" ,"1625" ,"25" ,"4/2015" #Like a credit card expiration ); foreach my $DateString (@PartialDates) { my $ParsedDate = ParseDate($DateString); print "Partial date, $DateString, creates a parsed date of $ParsedDate.\n" } produces this output Partial date, apr. 17, 1625, creates a parsed date of . Partial date, apr 17 1625, creates a parsed date of 1625041700:00:00. Partial date, April 17, 1625, creates a parsed date of 1625041700:00:00. Partial date, April 17, 25, creates a parsed date of 1925041700:00:00. Partial date, April 1625, creates a parsed date of 1925041600:00:00. Partial date, Apr 1625, creates a parsed date of 1925041600:00:00. Partial date, Apr. 1625, creates a parsed date of . Partial date, 1625, creates a parsed date of 1625010100:00:00. Partial date, 25, creates a parsed date of 2500010100:00:00. Partial date, 4/2015, creates a parsed date of . As I said a string with partial date is not a date string so it is difficult to consider this a defect with Date::Manip. I have a work around at this time for my application. I peek at the date to be parsed and prepend a 01 if only 2 elements are detected by the split. This was my motivation for the categorization of unimportant. I am not providing a true date string and I have a work around. Thank you again for Date::Manip. -- In Liberty, John Washburn
Although I definitely sympathize with you, Date::Manip works with full dates. I'll have to think about adding support for partial dates... the functionality would not be too hard to add, but this is definitely a lower priority for me. Also, I'll have to decide how to work with conflicts between the formats currently supported and potential partial dates. For example, the example you give (April 1625) is definitely defined to be April 16, 25 as you note. I want to keep that if it's being parsed as a complete date, but if it's a partial date, it makes more send to be April 1, 1625.

Probably, I'd want to add a parse_partial method or something like that.

Anyway, I'll consider this for future addition.

Subject: RE: [rt.cpan.org #53099] ParseDate(April 1625) = 1925041600:00:00
Date: Mon, 4 Jan 2010 12:48:21 -0500
To: bug-date-manip [...] rt.cpan.org, john [...] washburnresearch.org
From: "john [...] WashburnResearch.org" <john [...] WashburnResearch.org>
I appreciate your prompt response on this. As I stating in the original report, I am not even sure I consider this a defect. It is more in the way of an enhancement request. Other partial dates resolve to the interpolation I described; e.g. 1625-04 --> 1625040100:00:00, and 1625 --> 1625010100:00:00. I am not providing a fully specified date, so the fact that code happenstancially interpolates in most cases is not a design defect. BTW, I don't mind the current interpolation, but most Genealogists would hate it. It is better to have no information, than wrong information. Thus, the New England Genealogical Society would prefer April 1625 parse as 1625040000:00:00 than as 1625040100:00:00. Better no date information (00) than incorrect date information (01). But this is not a proper date (but then neither is April 1625 so there). As you stated partial dates are an interesting problem, but not necessarily your problem. :-) Thank you again for your response and your consideration of this enhancement request. -------------------------------------------------------------------- mail2web.com – What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint