Re: Re: setting TZ causes Date::Manip to report incorrect time

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

OK, lets find a framework for the comparison. I'm very much interested in this.

Here's some suggestions for comparison of results:

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

I think the next place to go from here is to make a list of tasks that each module is to perform. Anyone reading this who is an advocate of Date::Manip? I'd hate to create a list of tests only to be told DateTime wins simply because all the tests were written by a DateTime developer.

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]

Test	Date::Manip	DateTime	Commend
Acurateness of results	0	1	As evidenced by the post, Date::Manip does not work.
Brevity of Code	1	0.9
Understandability of code	0.6	0.8	Both have their weaknesses here. They both use the symbol %c, which is not too clear. However in DateTime, we see the command for the %c right next to it, rather than in D:M where the command is back at the start of the line. I also took points off D:M for the use of %ENV. Looking at this snippet in a large script, it wouldn't be too obvious that the two commands were related in any way.
	1.6	2.7

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.

Comment on Re: Re: setting TZ causes Date::Manip to report incorrect time Download Code

Replies are listed 'Best First'.
Re: Re: Re: setting TZ causes Date::Manip to report incorrect time by exussum0 (Vicar) on Sep 10, 2003 at 09:34 UTC
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..	[reply]
Re: Re: Re: Re: setting TZ causes Date::Manip to report incorrect time by autarch (Hermit) on Sep 10, 2003 at 15:53 UTC
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.	[reply]