in reply to setting TZ causes Date::Manip to report incorrect time
initially, i also had time zone problems using Date::Manip
however, for myself, the following, at the head of a script using Date::Manip, solves the problem:
Date_Init("TZ=GMT", "WorkDayBeg=$wdb", "WorkDayEnd=$wde");
with s/GMT/yourtimezone, ($wdb, $wde) = ("08:00", "17:00").
as for the list of timezones, i found them in the Date::Manip perldoc too, but yes, no mention of
"PST8PDT". Thelonius gets his info from the source itself,
where you will find PST8PDT, MST7MDT, CST6CDT etc. i believe these are shorthands for 'US/Pacific', 'US/Mountain', which are in the documentation for Date::Manip.
given that Date::Manip is as useful as it is, esp. for business day calcs, it is a pity the docs are not a little more expansive on the subject.
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:
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.
In addition formats parsed and output by Date::Manip are really extensive. It has been the only date module i have ever needed, and "use Date::Manip" is not exessively cluttery.
however, i have to say, i found it took me a while to get to grips with the intricacies of this important but labour-intensive module. i see no tutorials in PM involving Date::Manip; has the time come for one?
here is hoping...
wufnik
...in the world of the mules there are no rules
Re: Re: setting TZ causes Date::Manip to report incorrect time
by autarch (Hermit) on Sep 09, 2003 at 16:20 UTC
|
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";
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. | [reply] [Watch: Dir/Any] [d/l] |
|
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");
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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 --
| [reply] [Watch: Dir/Any] |
Re: Re: setting TZ causes Date::Manip to report incorrect time
by BigLug (Chaplain) on Sep 10, 2003 at 04:46 UTC
|
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()
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. | [reply] [Watch: Dir/Any] [d/l] |
|
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] [Watch: Dir/Any] |
|
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] [Watch: Dir/Any] |
|
|