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

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..

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]