in reply to Re^2: Ovid's "Please Stop Using Perl 3"
in thread Ovid's "Please Stop Using Perl 3"

Date::Manip is ancient and was highly regarded for being very flexible (especially at parsing date strings of unknown format) but noted for being quite "slow". It certainly isn't a "new date/time module" that people are trying to standardize on.

I still see quite a few different date/time modules being suggested so consolidation is not working very well yet from my perspective. I recall that there is work being done on some Holy Grail suite of Perl date/time modules but don't recall the namespace (it was something really simple like DateTime::*), which might say something about why consolidation isn't finished. I certainly don't have a good idea where I'd go to figure out which date/time module currently has the most support and that is part of why I don't use any date/time modules.

I just use localtime, gmtime, and Time::Local and sometimes POSIX::strftime() and would find learning some module time-consuming and fully expect to find using the module to be quite frustrating. But I'm sure most peoples' mileage will vary.

- tye        

  • Comment on Re^3: Ovid's "Please Stop Using Perl 3" (Date::Manip)

Replies are listed 'Best First'.
Re^4: Ovid's "Please Stop Using Perl 3" (Date::Manip)
by nevyn (Monk) on Sep 07, 2006 at 17:18 UTC

    Well I've never cared about the "slow" aspect, I often want it where I have a string which represents a "date and time" and I just pass it to ParseDate() and that "just works".

    In many cases strptime would work and I might use that with strftime etc., if it was in core ... but it seems worthless to pull a module in for strptime, when I can just pull Date::Manip in instead.

    How do you parse date/time strings?

    --
    And-httpd, $2,000 security guarantee
    James Antill
[reply]
      How do you parse date/time strings?

      I don't parse dates in unknown formats. Most date strings I deal with can be parsed with /(\d\d)/g, as it should be. On rare occasions I've worked with worse formats but the worst case was just building a simple hash of month abbreviations.

      When I do parse date strings, I usually parse one per line for tons of lines and so "slow" adds up quickly and so I probably wouldn't use Date::Manip.

      Thanks for pointing out how much else Date::Manip does well.

      - tye        

[reply]
        I don't parse dates in unknown formats.

        Right, I guess I've probably done an above average number of scripts which do reports and take date arguments. A problem which ParseDate was basically written to solve.

        And thinking about it more, I have written a couple of things like my "And-httpd syslog" => "Apache-httpd combined log" converter, which are basically regexps + hash and they would be more painful to do with Date::Manip (and speed does matter). But implementing the "skip enteries before time X" option, without it, would be bad :).

        --
        And-httpd, $2,000 security guarantee
        James Antill
[reply]
Re^4: Ovid's "Please Stop Using Perl 3" (Date::Manip)
by Anonymous Monk on Sep 07, 2006 at 14:34 UTC
    I just use localtime, gmtime, and Time::Local and sometimes POSIX::strftime() and would find learning some module time-consuming and fully expect to find using the module to be quite frustrating. That's what I tend to do, too. Time::Local and POSIX both seem to be part of the core distribution, as of 5.6.1. This is a good thing.
[reply]

In Section Meditations