Using only modules included with Perl...

Relative to current date:

use Time::Local qw( timelocal_nocheck );

my @time_data;

@time_data = localtime();

$time_data[4]++;   # Next month.
$time_data[3] = 0; # Last day of previous month.

@time_data = localtime(timelocal_nocheck(@time_data));

my $year     = $time_data[5]+1900;
my $month    = $time_data[4]+1;    # Make 1-based
my $last_day = $time_data[3];

printf("The last day of this month (%04d/%02d) is %d.\n",
    $year, $month, $last_day
);

__END__
output
======
The last day of this month (2005/01) is 31.
[download]

Relative to a specified year and month:

use Time::Local qw( timegm_nocheck );

my $year = 2005;

for my $month (1..12) {
   my $last_day = (gmtime(timegm_nocheck(
      0, 0, 0,
      1-1,        # Last day of previous month.
      $month-1+1, # Next month (0-based).
      $year
   )))[3];

   printf("The last day of %04d/%02d is %d.\n",
       $year, $month, $last_day
   );
}

__END__
output
======
The last day of 2005/01 is 31.
The last day of 2005/02 is 28.
The last day of 2005/03 is 31.
The last day of 2005/04 is 30.
The last day of 2005/05 is 31.
The last day of 2005/06 is 30.
The last day of 2005/07 is 31.
The last day of 2005/08 is 31.
The last day of 2005/09 is 30.
The last day of 2005/10 is 31.
The last day of 2005/11 is 30.
The last day of 2005/12 is 31.
[download]

I just thought i should mention something regarding this question. To me its probably a sign of bad design when a system requires logic to determine end of month dates (unless its a date module in of itself...)

IME the most common reason to require an end of month date is when you have dated assignments, such as "this customer pays that rate from this date to that date". A naive DB implementation would have the start date and end date be inclusive, so an assignment for january would be Jan 1 - Jan 31. This is a problematic design for many reasons. It requires annoying code to determine the end of the month, and it makes writing queries much more difficult by introducing a bunch of weird edge cases. For instance if the From date is Jan 01 00:00:00 and the To date is Jan 31 00:00:00 what happens for the 24 hours following Jan 31? So now you have to start doing things like Jan 31 23:59:59, which is just a pain. Range queries likewise become really annoying. (To make matters even worse, its not unusual to use NULL as an end date to imply an "open assignment". This just makes queries more complex and slower.)

A much better design IMO is to make date ranges inclusive on the from date and exclusive on the to date, in other words an interval [From,To) and require that end dates are defined (use a far future date to represent open assignments). This makes the logic much simpler. You avoid dealing with end of month dates as you can say Jan01-Feb01, you avoid dealing with time gap problems, and can reduce quite complex queries down to very simple logic. For instance to find all assignments for a particular customer for a particular time period you can say:

  select * from assignment
  where customer=$customer
  and start_date   < $end_period
  and $start_period < end_date
[download]

I actually do agree all of your post but this:
>   To me its probably a sign of bad design when a system requires logic to determine end of month dates.
Working for a financial institute I know of many cases where "end of month" has a business related meaning. Often dates for payments, rate-fixings etc. are set in a way like "last working date in month X".

pelagic

You should pick the module and learn to use it yourself, but in general: add one day to the date; if the result is the first day of a month, the date used was obviously the last one.

use strict;
use warnings;

print monthdays('Jan',1998), "\n";
print monthdays('FEB',1999), "\n";
print monthdays('FeB',2000), "\n";
print monthdays(2,2100), "\n";

# Takes two arguments, both required:
# Month - can be either numerical in the range 0-11, or alphabetic,
#         ignoring case.
# Year - 4-digit format recommended.
BEGIN {
    my %md_mon = ('JAN',1,'FEB',2,'MAR',3,'APR',4,'MAY',5,'JUN',6,
                 'JUL',7,'AUG',8,'SEP',9,'OCT',10,'NOV',11,'DEC',12);
    my @md_mon = (0,31,28,31,30,31,30,31,31,30,31,30,31);
    sub monthdays {
        my ($m, $y) = @_;
        $m = $md_mon{uc($m)} if $m =~ /[a-zA-Z]/;
        my $d = $md_mon[$m];
        $d++ if $m == 2 && $y % 4 == 0 && ($y % 100 != 0 || $y % 400 =
+= 0);
        return $d;
    }
}
[download]

If you really just need the last day of the month (rather than the last business day), you might use Date::Simple. You shouldn't have to do fancy tricks with date manipulation to get a simple answer.

use Date::Simple qw(days_in_month);

my $days = days_in_month( 2004, 2 );
[download]

perl -MDate::Manip -le \
     'print UnixDate DateCalc(ParseDate("@ARGV"), "+1m -1d"), "%e"'
[download]

Just make sure to read the SHOULD I USE DATE::MANIP section in the module's POD.

Makeshifts last the longest.

I'm well aware of its content.

I'd still use Date::Manip if I were to calculate it. If it's going to be run as a time critical program, the program would either be written in C, or a lookup instead of a calculation would be used.

  use Date::Object ;
  
  my $d = Date::Object->new_local(2005 , 1 , 5) ;
  
  my $d_end = $d->clone->set(undef,undef,31) ; ## set(YYYY , MM , DD)

  print "date:     $d\n" ;
  print "date end: $d_end\n" ;
  
  if ( $d == $d_end ) {
    print "Date is the last day of month!\n" ;
  }
[download]

date:     2005-01-05 00:00:00
date end: 2005-01-31 00:00:00
[download]