in reply to Re: Broken Date Handling
in thread Broken Date Handling

Yeah. So I fixed it by adding

$d += 0;

to the code.

The script doesn't fail in September. But it fails on both the 8th and the 9th of every month.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Replies are listed 'Best First'.
Re: Re: Re: Broken Date Handling
by jj808 (Hermit) on Oct 10, 2002 at 10:53 UTC
    Why doesn't it fail in September then? Or August, for that matter?

    Of course, you've already done a calculation on that value. Doh.

      Because the $m-- converts $m to a number.

      --
      <http://www.dave.org.uk>

      "The first rule of Perl club is you do not talk about Perl club."
      -- Chip Salzenberg

        Meditation, sort of.
        Thanks for sharing this Davorg.
        So is there some general wisdom we can glean from this?
        Davorg was being clever, (no harm in that, hubris is good, right?). He likely felt justified in being clever, 'cos an eval'd timelocal would do the error checking for him. (Most of us would feel nice and comfy about that).
        But crikey, it's a very serious error if it were to make its way into production code, the sort that gives ammo to Perl naysayers, imho.
        Would more extensive testing have caught this? Undoubtedly yes.
        Should Davorg have used a CPAN module like Date::Calc, or is that overkill? Maybe only he can decide.
        Would this have happened if Davorg was coding in Java? Probably not, (but he'd still be working on the app.)
        Is there a general rule we can apply to prevent ourselves from getting burnt like this?
        TIA,
        Perlcgi