Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

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

by wufnik (Friar)
on Sep 09, 2003 at 09:07 UTC ( [id://289968]=note: print w/replies, xml ) Need Help??


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

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

      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
      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 --
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()
    TestDate::ManipDateTimeCommend
    Acurateness of results01As evidenced by the post, Date::Manip does not work.
    Brevity of Code10.9 
    Understandability of code0.60.8Both 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.62.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.

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://289968]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (6)
As of 2024-03-28 21:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found