If you're in March, on the 29th, 30th, or 31st, then the previous date you'd get your way won't work for Feb, 11 out of 12 times. (The 29th will work every 4 years, at least from now until 2100 :))

Obviously, you'll have the same problem every time a month with 31 days follows a month with 30, as well...

Date::Calc is clearly the way to go for this problem.
--
Mike

Ahh, while the deeper parts of this thread explain why that's a nasty thing to do for specific dates, in this particular application you should be fine. Our noble friend Anonymous Monk is just looking to roll the month back, so he can take those month values and work with them. Of course, he'll want to check to see if he's working with December and January, but otherwise, grabbing the month (and throwing a zero onto the front of a short one) should suffice. Working with the previous code (hacking stupidly, rather than grabbing a pretty module here), and handling both this and last month...


($month, $year) = (localtime)[4..5];
# convert from index to 'normal'
$this_months_year = $year + 1900;
$last_months_year = $this_months_year;
$this_month = $month + 1;
# fix month if = 0
$last_month = $month;
$last_month or $last_month = 12;
# roll back year if this month is january
($this_month == 1) and $last_months_year--;
$this = sprintf("%04d%02d", $this_months_year, $this_month);
$last = sprintf("%04d%02d", $last_months_year, $last_month);

@files_this = <companyname.com-$this??_log>;
@files_last = <companyname.com-$last??_log>;
[download]


I think that looks a bit ugly, but that should at least illustrate why it's a good idea to peek into those date related modules. As a sidenote.. did I miss anything else in there, or should that ugly hack do the trick?

-=rev=-

NICE ugly hack :)

In fact, I used to have code very much like that.

Then someone changed the interval from "1 month" to "20 days", and I started wishing I'd used Date::Calc right from the start...

But your way should work fine for what he needs, as long as the specs don't change down the road.
--
Mike

Let me understand this.

Shouldn't localtime return a value based on the OS date? So, how come it won't work?

I need to clear this out.

Er Galvão Abbott
a.k.a. Lobo, DaWolf
Webdeveloper

DaWolf,

Imagine it's the 31st March. You subtract 1 from the month and get 31st February - which isn't a valid date.

A similar problem occurs when it's any day in January. You subtract one from the month and get -1...

Hope this helps!

Yes you can do it yourself fairly easily, but there are already modules which do this correctly, so you might as well not reinvent the wheel unless yours is a different shape.

Alan

...okay then, how about this?

You didn't like this:

       @t = (localtime)[0..5];
       $this_month = $t[4]+1;
       $previous_month = $t[4];
[download]

But if it is changed slightly,

       $this_month = (localtime)[4];
       $previous_month = $this_month++ ? $this_month-1 : 12;
[download]

This idea raises hackles for me because it depends upon order of evaluation, and it "cleverly" hides the logic of its decision mechanism (as the conditional operator often does), but it does account for the border case.

---v

That gets the month right, but still doesn't take the year into account.

And, as others have stated (but I forgot): if you care about the day as well, then you need to add more code to make sure that "one month before March 31" results in "February 28th or 29th depending on whether it's a leap year" and not "February 31st".

It all depends on what problem you're trying to solve. If all you need is the right month, then your solution works in a clever way. But you're right, it's not the clearest code in the world... :)

Alan