Does this mean that Date::Manip has problems with timezones, as BigLug suggests? i think the docs, rather than the code, are the problem. it would be interesting to see a proper comparison of DateTime functionality with Date::Manip; i would be surprised if Date::Manip came off worst:

Well, as someone who's used every datetime module under the sun, and then got sick of them and wrote DateTime, I wouldn't be surprised if Date::Manip came off worse, because I know that it will.

Specifically, try doing this with Date::Manip:

 my $dt1 = DateTime->new( year => 2003, month => 5, day => 2,
                          hour => 7, minute => 53,
                          time_zone => 'Asia/Tokyo' );
 my $dt2 = DateTime->new( year => 2003, month => 5, day => 2,
                          hour => 5, minute => 53,
                          time_zone => 'Asia/Calcutta' );

 if ( $dt1 > $dt2 ) {
     ...
 } else {
     ...
 }

 $dt1->set_time_zone( 'Asia/Calcutta' );

 print $dt1->datetime, "\n";
 print $dt2->datetime, "\n";
[download]

If that sort of thing is even possible with Date::Manip, it'd be much, much, much more code.

Date::Manip can alter the number of seconds in the day via "WorkDayBeg" and "WorkDayEnd" in Date_init() (see above), so it, at least, does not suffer from making the assumption that there are 24*60*60 seconds in a day.

What BigLug was referring to when he mentioned this was the existence of leap seconds, not the idea of "business hours". Some days last longer than 24*60*60 seconds on the clock, according to the UTC system. However, this only happens to one day every couple years or so. You can't simply change the length of the day and leave it at that. That would be quite broken.

So I'll take your challenge and say .. I think its working, if you dig into how its intended to work. Using your exact example dataset, I reformatted it for Date::Manip. Some may have other opinions on how to set the date, but this is compact and for me easy to follow:

use strict;
use warnings;

use Date::Manip;

my $dt1 = Date::Manip::Date->new();
my $dt2 = Date::Manip::Date->new();

$dt1->config("setdate","zone,Asia/Tokyo");
$dt2->config("setdate","zone,Asia/Calcutta");

$dt1->parse("20030502T07:53");
$dt2->parse("20030502T05:53");

if ( $dt1->cmp($dt2) ) {
   print "dt1 ftw!\n";
} else {
   print "dt2 ftw!\n";
}

print $dt1->printf("dt1 %c %Z\n");

$dt1->convert("Asia/Calcutta");

print $dt1->printf("dt1 %c %Z\n");
print $dt2->printf("dt2 %c %Z\n");
[download]

Output is:

$ perl ./testdate
dt1 ftw!
dt1 Fri May  2 07:53:00 2003 JST
dt1 Fri May  2 04:23:00 2003 IST
dt2 Fri May  2 05:53:00 2003 IST
[download]

autarch, those seem eminently reasonable points.

the two modules evidently occupy similar niches. while your example above is persuasive, it would be surprising if Date::Manip did not have strengths it would be too tedious to mention.

i think what would be very helpful to the general monk population is a pithy comparison table, outlining the various points that would be useful, and whether datetime or date::manip holds the higher ground. BigLug suggested as much.

what better way to convince us of your assertion:

i know that it will. ?

best wishes, ...wufnik

-- in the world of the mules there are no rules --

it would be interesting to see a proper comparison of DateTime functionality with Date::Manip; i would be surprised if Date::Manip came off worst

Here's some suggestions for comparison of results:

• Acurateness of result
• Brevity of code
• Understandability of code
• Reusability of data

Please, anyone, tell me the tasks you use Date::Manip for. From the top post in this thread I assume we want the current time and date in the local time zone, formatted in the locally preferred format.

use Date::Manip;
$ENV{TZ} = 'EST';
print UnixDate(ParseDate("today"),"%c");
#use Date::Manip;$ENV{TZ}=;print UnixDate(ParseDate(),)

use DateTime;
print DateTime->now(time_zone=>'Australia/Melbourne')->strftime("%c");
#use DateTime;print DateTime->now(time_zone=>)->strftime()
[download]

Scoring:
Acurateness of results: 1 if accurate, 0 if inaccurate
Brevity of Code: 1 for the shorter code, once data has been removed. Then the longer gets shorter/longer.
Understandability of code: Value judgement.

Of course, I'm open to any criticism, additions and corrections to my comparison. I'd really like to create a fair comparison of various common tasks. Send me your code and your comparisons. Or just send me your test-in-english and I'll code them both.

Well, if an algorithm had 50 lines of code to add 2 numbers together, and another had 25 lines, you may argue that the shorter is better.. but define better. Does the 50 line one take in special occurrences so that it does things faster? Is it clearer to read? Don't create statistics for thse types of subjective things unless they have a real concrete measurement, like in seconds vs data for performance. It just mucks up the works.

If something is better in one way that can't be proven by numbers, just say so. "CGI.pm - it works, but he innards look like shit, but it's a proven standard" Same with Date::Manip - "It's a standard module, but it works like shit when you throw certain data at it.. though DateTime works and is new."

People will make their own judgements depending on their needs. Like cricket. It's a really ugly script, but you know, it works. It works well and is very configurable, but it's easy to miscnfigure and berak. So will you use it over something that is unbreakable but limited? That's up to you. :)

Lies, bigger lies, and then there are statistics, to paraphase :)
--
Play that funky music white boy..

Actually, DateTime is already becoming more of a standard than Date::Manip, because it is designed to play well with others. So we see other, non-datetime module authors supporting it. For example, in SPOPS, Chris Winters now support DateTime objects for setting datetime values in a database. He also supports Time::Piece & Class::Date, but it defaults to DateTime.

And other datetime module authors are starting to look to DateTime as a standard as well. Matt Sergeant has a working beta of Time::Piece 2.0x, which will simply be a DateTime subclass. He has said that he hopes to see users of Time::Piece eventually move to DateTime itself. Similarly, Graham Barr asked me not long ago when DateTime would replace his TimeDate distro.

People like DateTime because it not only does everything they need, but it has a design, and a plan for the future, and it plays really nice with everyone else. Date::Manip does a lot of stuff, but the API is a mess, and it doesn't integrate well with any other datetime modules. Similarly, Date::Calc also does a lot of stuff, but it doesn't play well with others at all.