Skip Menu |

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

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

People
Owner: Nobody in particular
Requestors: mblythester [...] gmail.com
Cc:
AdminCc:

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



Subject: Date::Manip doesn't handle "illegal" dates well.
Date: Mon, 23 Aug 2010 17:28:28 -0600
To: bug-Date-Manip [...] rt.cpan.org
From: Matt Blythe <mblythester [...] gmail.com>
I was going to rant about how Date::Manip can't parse dates on March 14th, 2010, but then I realized that my particular date & time was in the 1-hour no-man's-land during the "spring forward" hour of the daylight saving time adjustment. :-) So, my new request is to please output a more friendly error message in cases of ambiguous dates. The following script: use Date::Manip::Date; $date = new Date::Manip::Date; $date->parse("3/14/10 2:58"); print $date->secs_since_1970_GMT()."\n"; print $date->value()."\n"; produces the following output: Use of uninitialized value $y in integer lt (<) at C:/Users/mblythe/perl/perl/si te/lib/Date/Manip/Base.pm line 2225, <DATA> line 335. Use of uninitialized value $y in concatenation (.) or string at C:/Users/mblythe /perl/perl/site/lib/Date/Manip/Base.pm line 2226, <DATA> line 335. Use of uninitialized value $m in integer eq (==) at C:/Users/mblythe/perl/perl/s ite/lib/Date/Manip/Base.pm line 2228, <DATA> line 335. Use of uninitialized value $d in integer eq (==) at C:/Users/mblythe/perl/perl/s ite/lib/Date/Manip/Base.pm line 2229, <DATA> line 335. Use of uninitialized value $h in integer eq (==) at C:/Users/mblythe/perl/perl/s ite/lib/Date/Manip/Base.pm line 2230, <DATA> line 335. Use of uninitialized value $mn in integer eq (==) at C:/Users/mblythe/perl/perl/ site/lib/Date/Manip/Base.pm line 2231, <DATA> line 335. Use of uninitialized value $s in integer eq (==) at C:/Users/mblythe/perl/perl/s ite/lib/Date/Manip/Base.pm line 2232, <DATA> line 335. Use of uninitialized value $m in concatenation (.) or string at C:/Users/mblythe /perl/perl/site/lib/Date/Manip/Base.pm line 2233, <DATA> line 335. Use of uninitialized value $d in concatenation (.) or string at C:/Users/mblythe /perl/perl/site/lib/Date/Manip/Base.pm line 2233, <DATA> line 335. Use of uninitialized value $h in concatenation (.) or string at C:/Users/mblythe /perl/perl/site/lib/Date/Manip/Base.pm line 2233, <DATA> line 335. Use of uninitialized value $mn in concatenation (.) or string at C:/Users/mblyth e/perl/perl/site/lib/Date/Manip/Base.pm line 2233, <DATA> line 335. Use of uninitialized value $s in concatenation (.) or string at C:/Users/mblythe /perl/perl/site/lib/Date/Manip/Base.pm line 2233, <DATA> line 335. Use of uninitialized value $beg in string comparison (cmp) at C:/Users/mblythe/p erl/perl/site/lib/Date/Manip/TZ.pm line 1069, <DATA> line 335. Use of uninitialized value $end in string comparison (cmp) at C:/Users/mblythe/p erl/perl/site/lib/Date/Manip/TZ.pm line 1071, <DATA> line 335. Use of uninitialized value $year in addition (+) at C:/Users/mblythe/perl/perl/s ite/lib/Date/Manip/TZ.pm line 1072, <DATA> line 335. Use of uninitialized value $d in integer addition (+) at C:/Users/mblythe/perl/p erl/site/lib/Date/Manip/Base.pm line 466, <DATA> line 335. Use of uninitialized value in integer addition (+) at C:/Users/mblythe/perl/perl /site/lib/Date/Manip/Base.pm line 466, <DATA> line 335. Use of uninitialized value $h in multiplication (*) at C:/Users/mblythe/perl/per l/site/lib/Date/Manip/Base.pm line 573, <DATA> line 335. Use of uninitialized value $mn in multiplication (*) at C:/Users/mblythe/perl/pe rl/site/lib/Date/Manip/Base.pm line 573, <DATA> line 335. Use of uninitialized value $s in addition (+) at C:/Users/mblythe/perl/perl/site /lib/Date/Manip/Base.pm line 573, <DATA> line 335. -62135769600 I can imagine (but I haven't tried) that the corresponding date in November (when an hour is repeated) might throw similar errors. I'd appreciate it if Date::Manip would identify these ambiguous date/times and print a friendlier error message...something like: "The date you specified: '3/14/10 2:58' does not exist due to daylight saving time adjustments. Please specify a timezone (e.g. EDT)" or "The date you specified: "11/??/10 2:34" is ambiguous due to daylight saving time adjustments. Please specify a timezone (e.g. EDT)" A message like this would have saved me quite a bit of head-scratching (and thinking that Date::Manip was broken...) System info: strawberry perl portable 5.12.1.0 on windows 7 and XP Date::Manip 6.11 installed through CPAN Thanks! -Matt
There are actually three separate issues here. First, Date::Manip DOES produce error messages... you just never looked at it :-). Take a look at the following version of your script: ================= use Date::Manip::Date; $date = new Date::Manip::Date; $date->parse("3/14/10 2:58"); if ($date->err()) { print $date->err(),"\n"; exit; } print $date->secs_since_1970_GMT()."\n"; print $date->value()."\n"; ================= This script would have produce the output: [set] Invalid date/timezone and no uninitialized value messages. Your script called the secs_since_1970_GMT method, which requires a valid date object, but you didn't have a valid date object. Garbage in... garbage out. This brings us to issue two. A better failure mode for the secs_since_1970_GMT method would have been to exit immediately instead of performing an operation with invalid input which resulted in all those messages. I'll look into correcting that. Issue three is the error messages. I'll look into improving some of the error messages... however, because parsing is a very complicated process, it is doubtful that I'll make them as "complete" as you suggest. Parsing is broken up into many pieces... the timezone, the time, the day-of-week (when present), the date, are all parsed separately. When I get an error, I don't necessarily have all of the pieces of information in one place to determine what is the root cause of the error (i.e. is this a case of being in the 1-hour no-man's land during a time change, or did something else cause the problem). So, I won't always be able to give a complete diagnostic message describing the problem. Still, I may be able to improve what I've got, so I'll spend some time on that. Hope this helps.