The fact that this module exists, with it's easy handling of natural language, is amazing. Thanks for the module, it's saved much time, and increased the level of usability for my application considerably.
I support the 5.10 requirement as well; those who don't/can't/won't upgrade for whatever reason have no reason to expect the latest features. Find a way, or live with the consequences.
This module is not for everyone, nor for every use, as the documentation takes pain to point out.
However, most of the other objections noted in reviews here (requires 5.10, too many timezone files, date objects too big) have been fixed, or at least their causes clearly explained, in the most recent version.
To repeat, in case I wasn't clear: Perl 5.10 is no longer required for the backwards-compatible version of the API (it is required for the clean new OO API).
Wow, there are surely a lot of negative reviews ...
First of all, Date::Manip has a long history. I used this module back in 2001-2002, IIRC. Back then it was *the* swiss army of date/time manipulation, something you use when you want the most flexible/complete thing in Perl. True, it's slow, but it works.
But then things change. DateTime project was started, and now it is somewhat the de facto standard. It's more modern and far more modular than the monolithic Date::Manip (every timezone and language support and parsing/formatting modules shipped in one single distribution).
And then there's the 5.x -> 6.x debacle. As someone who also sprinkle Perl 5.10 requirements to his CPAN modules, I can feel for the author. But the difference is, most of my modules are not that widely used/known, and also many start its life already requiring 5.10 right from its first released version. While in Date::Manip's case, this happens to a very widely used module. Surely backwards compatibility should be considered more.
All in all, you are free to use or not use Date::Manip. There are other alternatives. Pick wisely.
For those who have experienced problems upgrading Date::Manip on systems running older versions of perl, this problem is handled in Date-Manip-6.10.
I discuss this problem (and the other complaints given in the CPAN ratings) in the Date::Manip::Problems document. Please check it out if you have any questions concerning some of the complaints raised here.
I'm dumbfounded that anyone would update an existing module and not make it compatible with earlier perl releases, especially considering the inability to specify specific module versions in prerequisites.
Could the author not have at least created a new module called Date::Manip510 for those who wish or are able to upgrade their perl.
That way the rest of us can continue to install software in a perl5.6/perl5.8 environment without having to manually install the older release.
I am really loathe to give negative reviews, but I'm notably unimpressed that release 6.x of Date-Manip has a requirement on Perl 5.10. Backward compatibility was sacrificed for "the ability to do named capture buffers". I'm very sorry, but while I feel the author is completely free to do whatever he desires with his own distribution, I find the decision to mandate 5.10 quite unfortunate. As another reviewer had mentioned, this decision will have negative affects in various enterprise environments.
Other than this one unfortunate decision, the distribution is otherwise quite excellent.
This was one of my favorite modules, but the 6.x release is a huge step backwards. I'm going to have to use 5.54 forever I guess. Requiring 5.10 is going to lock quite a few people out, especially in large enterprise environments where it's already difficult to deploy CPAN stuff. It's sad really... but I still see a lot of perl5.6 out there.
Seriously, that's ridiculous - that's far too much data to link to an instance. You cannot sensibly serialize something like that using 'Storable' etc - a shame, because one of the strengths of using Date::Manip has always been its extremely lightweight memory use - 'YYYYMMDDHH:MM:SS+ZZZZ' is a very efficient format.
Does it seriously need more than: [ $iso, $epoch, $offset_sec, $zone ] ?
It's a great module and it does what it is advertised.
However, it's rare that my task requires the use of this module, and for that reason, I always find myself referring to the documention; that part always makes me utterly annoyed. I always find myself scrolling back and forth trying to remember what routine(s) I used to use in the past.
To the author I would suggest using more =head elements in the pod - even for every method/function and even arguments. This way one, who probably used the module in the past, can just glance at the Table of Contents and go "Aha! these two are the ones I used before!".
This is my favorite module for parsing dates, especially when I don't want to spent time figuring out all the possible date formats of my data source. Only in a very few cases have I had to replaced it with a faster date parser. It's ease of use makes it one of the handiest date parsers in CPAN. Thanks Sullivan!
I've been using Date::Manip for years and I need it so often. It is a little quirky, and probably overkill for the simplest cases, but dates always get complicated eventually, so it's worth your time to learn this module.
Slow! If you are going to use it to parse tens of thousands of dates, you may look into another module or do the parsing by hand.
On the other hand this is a very complete, well documented module that brings a lot great functionality.It also has a bunch of tests. The code is not documented a lot but it's nice and clean (and big).
A well deserved 5 stars for a module author that does a serious job.