http://www.perlmonks.org?node_id=31944

Item Description: The Perl module for handling dates

Review Synopsis: it rocks. 'nuff said.

I first learned of this module from my copy of the Perl Cookbook (the 'Ram' book). Date::Calc enables you to do just about anything there is to be done with dates, much of it with built-in functions, and handles just about every sensible date format there is.

Replies are listed 'Best First'.
Re: Date::Calc
by ishmael (Novice) on Jun 13, 2001 at 12:25 UTC

    This is a great module. The comment on performance and Perl is well placed. This module will not be slowing down your code any more than the Perl interpreter itself.

    One useful additional feature that this module would benefit from would be

    • given a date, what week of the month is it on? for example, Jun 13th 2001 lies in the 3rd week of June 2001.
    • given a date, what is the ordinal of its day of the week in the month? for example, Jun 13th 2001 is the 2nd wednesday of June 2001
    • given two dates, calculate the difference in business days. for example, (Jun 13th 2001)-(Jun 8th 2001) = 3 business days
    • likewise, add n business days to any date
    • better support for unix timestamps (epoch time) values

    However, these can be fairly easily implemented within the framework of the module. I ishmael

      (1) given a date, what week of the month is it on? for example, Jun 13th 2001 lies in the 3rd week of June 2001.

      See the recipes section of the Date::Calc manual page, recipe #5: "How do I calculate the number of the week of month the current date lies in?"

      (2) given a date, what is the ordinal of its day of the week in the month? for example, Jun 13th 2001 is the 2nd wednesday of June 2001

      See the recipes section of the Date::Calc manual page, recipe #6: "How do I calculate whether a given date is the 1st, 2nd, 3rd, 4th or 5th of that day of week in the given month?"

      (3) given two dates, calculate the difference in business days. for example, (Jun 13th 2001)-(Jun 8th 2001) = 3 business days

      See method "delta_workdays()" in Date::Calendar

      (4) likewise, add n business days to any date

      See method "add_delta_workdays()" in Date::Calendar

      (5) better support for unix timestamps (epoch time) values

      See functions Gmtime(), Localtime(), Mktime(), Timezone(), Date_to_Time() and Time_to_Date() in Date::Calc

RE: Date::Calc
by cwest (Friar) on Sep 11, 2000 at 23:55 UTC
    And it's huge and clunky, 'nuff said.

    but seriously, you may be better off just rolling your own for a few conversions that loading that monolithic date hacking machine.

    --
    Casey
    
      I must disagree. Many people feel that Date::Calc is big and clunky. It is large, but the job it is performing it complicated and intricate. If performance is of maximal importance then I agree that you would be better off rolling a high-performance date routine that is custom-tailored to your needs (but if performance is your #1 concern, you probably shouldn't be using Perl either).

      However, if reliability and correctness of your code is important, then you should use Date::Calc. If you have spent any time doing serious date logic, you will understand the benefits of using a well-tested, full-featured library of date routines such as Date::Calc. Why re-invent the wheel, especially if you don't have to. Date arithmetic is particularly nasty (if you want to know just how nasty, check out Calenderical Calculations by Dershowitz and Reingold) and very easy to get wrong or introduce subtle errors. Heed my advice and always try Date::Calc (or another well-written and properly tested date module) before falling-back and writing your own.

        I must disagree with lhoward, who disagreed :-). Since Date::Calc is internally written in C, it is probably much faster than anything you could roll yourself, in Perl. -- Steffen Beyer sb@engelschall.com
      Actually, there are people who reported to me that they prefer to use Date::Calc instead of Date::Manip, because Date::Calc is more compact, takes less time to load and is faster (because it is written in C, internally) than Date::Manip, even though Date::Manip is more powerful for instance in parsing dates (natural language constructs are possible) and in calculations involving business days. -- Steffen Beyer sb@engelschall.com
      On the contary, it is huge and clunky because it is so fully featured.

      We use it extensively within our applications because of this and positively welcome and would willingly assist with future enhancements.

      I believe you only need to "use" the particular conversions relevant to your needs.
      Date/Manip.pm v5.54: 240908 Bytes
      Date/Pcalc.pm v6.0: 98112 Bytes
      Date/Calc.so v6.0: 125005 Bytes
      
      All under FreeBSD 7.2-STABLE AMD64 with Perl compile-time
      options (among others) USE_64_BIT_ALL and USE_64_BIT_INT.