Firstly, a personal preference: I hate seeing all variables declared at the top. Declare them as you use them.

The second thing that strikes me in your code is your declaration of your hash. You don't need to assign any value at all. Something like  my %hash; works perfectly. Or if you prefer:  my %hash = ();. That way you won't have to delete the key later.

Then there's no need to use @old as your <DATA> file handle can work inside the foreach:

foreach $old(<DATA>) { ... }
[download]

my %month_number;
@month_number{qw/Jan Feb Mar Apr May ... Dec/} = (0 .. 11);

print $month_number{Jan};
# 0
[download]

use DateTime;
use DateTime::Format::Strptime;

my $parser = DateTime::Format::Strptime->new(
   pattern => '%a %b %d %T EST %Y', # see the docs for the patterns
   locale  => 'en_US', # to get the month and day names to parse
   time_zone => 'America/New_York',
);

my $now = DateTime->now(time_zone => 'America/New_York');
foreach (<DATA>) {
   my ($dt) = $_ =~ /^(.+?)\s:\s/;
   $dt = $parser->parse_datetime($dt); # turn the string into a dateti
+me
   print $_
      if (($dt < $now) 
      and ($dt->add(days => 45) > $now))
}

__DATA__
Fri Dec 3 23:07:21 EST 2004 : Depth is : 234
Sat Dec 4 00:07:29 EST 2004 : Depth is : 123
Sun Dec 5 03:07:32 EST 2004 : Depth is : 144
Tue Feb 8 05:21:18 EST 2005 : Depth is : 11
Sat Feb 26 14:13:12 EST 2005 : Depth is : 4567
Fri Mar 11 17:09:38 EST 2005 : Depth is : 265
Sat Mar 12 07:07:27 EST 2005 : Depth is : 1654
Sat Mar 26 07:07:27 EST 2005 : Depth is : 1654
[download]

1. The pattern could use %Z instead of 'EST' in which case it wouldn't need to specifically declare the time zone. However 'EST' is an ambiguous zone and so we can't use it.
2. We add 45 days to the datetime and then check if it's greater than now rather than just subtracting it from now and checking that the difference is over 45 days because of the problems inherrent with date math ('daylight savings'/leap years/seconds etc.)
3. I also check that it isn't a future date, but if this is log parsing that shouldn't be a problem
4. If you only need day precision see the 'truncate' method in the DateTime documentation.
5. DateTime is the only set of modules that properly handle time zones and daylight savings (as well as handling international locales).

Also, as the conversion of mday and non-conversion of month and year (at lines 34-36) demonstrate, I just haven't "got" something in the litt re Time::Local.

Well as it turns out, this little bit from your code does confirm that opinion:

#...
    $mday = ( $2 - 1 );      # mday is in range 0-30 for timelocal
#...
[download]

(An interesting feature of Time::Local is that you can give it out-of-range values for some fields, and it will do the "right" thing; e.g. give it $mon=1 (Feb) and $mday=30, and it will give you epoch seconds for March 2 (or March 1, if it's a leap year). So the fact that you were passing "wrong" values for mday meant that you got unexpected retuen values, instead of some carp/croak/die behavior.)

As for the "year" value, timelocal is quite clever and forgiving about that -- if you haven't read the details about this in "perldoc Time::Local", you should.

Which leads me to the obscure detail in your initial regex that will need to be modified less than six years from now; surely you're not so young that you never heard of "Y2K bugs" -- you've got a "Y2K+10" bug. (But I know you'll be able to fix it in time. ;)

I would just use a hash to get from month name to month number. Setting it up can be tedious, but less so than devoting a whole subroutine to the task. Here is probably the least offensive way, all things considered:

my @mon_names = qw/Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec/;

my %mnth_str2digit = map { $mon_names[$_] => $_ } (0..$#mon_names);

# or, if map is "unintelligible to rookies", use a for loop:

my %mnth_str2dgt;
for ( 0..$#mon_names ) {
    $mnth_str2digit{$mon_names[$_]} = $_;
]
[download]

Apart from all that, I tend to agree with the first reply: if you're just doing this for the sake of practice with regexes and particular core modules, or if you really are in a situation where the presence of more powerful non-core modules simply can't be assured or controlled, that's fine -- knock yourself out.

But if relevant non-core modules are present, or you have the ability to install them as needed, it can often be a mistake to avoid using them for reasons like "my task is simple enough that I don't need a module" or "figuring out how to use the module will take too long" or "it'll make my script too complicated/difficult for me or others to follow". Regardng the first reason, even if it's true now, it might not be true later (e.g. when you get new/different data next week); as for the others, they tend to be imaginary and contrary to fact.

I happened to choose Date::Manip as a solution when I replied to grep for last 45 days -- it was just the first one that came to mind, and it was installed already, though I hadn't really used it at all. Starting cold, it didn't take more that 10 minutes to read enough of the man page and put together a 5-line script to solve the stated task, and I don't think the result was all that cryptic. (Okay, newbies would spend more time reading the man page and puzzling out how to use the module in a script, but still, they'd fare better that way than without the module.)