tye++ beat me to the punch.

You know, the eval STRING was the first thing that jumped at me when I looked at the snippet. Without any clue as to what the problem really was, I would first have suggested that the code would be much better off with a switch to eval BLOCK. Even simple economics would suggest so - the latter form does not have to hook back into the compiler at runtime.

For the record, assuming you really needed to stick with that form for whatever reason, then forcing numification of the day is just a kludge that only treats the symptom of your problem: you are treating user input data as code. This is the same class of problem that plagues all the simple, strictly stringifying scripting languages like Tcl. I was reminded of it immediately because I remember having to use a Tcl/Tk app at a job where entering 025 rather 25 in a text input box produced 21 (== 025 octal records) records - and there was no way at all to fix this, because of the way Tcl works. Fortunately, Perl is not Tcl. The real fix here is, or I should say would be, to eschew interpolation so that no user data makes it int your eval'd code:

eval "timelocal 0, 0, 0, \$d, \$m, \$y"; or better eval 'timelocal 0, 0, 0, $d, $m, $y';

Now the eval'd timelocal code will read the variables themselves, rather than be passed their stringified content.

That said, I consider eval STRING a red flag - a large flashing one actually. Whenever I see one or feel tempted to resort to it, I ask myself whether there really is no other way to accomplish that. Sometimes I'd go so far as to assert that if there isn't, maybe it shouldn't be done at all. There are very, very, very few cases where eval STRING ever is the proper approach, and esentially all of them have to do with doing some form of deep magic. It never is the right one if you're trying to solve a relatively ordinary problem - where "verifying dates for correctness" classifies as a terribly boring one.

eval STRING is the power to do anything. Be very, very afraid of it. Do not use without the proper amount of respect and awe.

Makeshifts last the longest.

In reply to eval $REDFLAG; by Aristotle
in thread Broken Date Handling by davorg

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.