Perl ships with Time::Piece as part of its core distribution. The documentation for that module describes date calculations and comparisons.

It's not the shiniest new module for date/time manipulation, but it comes with Perl (so you can't use the no external modules excuse), it will work, and its documentation is adequate for your purposes.

Update: One problem you may run into is that your times are ambiguous because they're not associated with a date. Is "endtime" always after "starttime"? Should "currenttime" be coerced to the next day if it's less than "starttime"? What rules should be followed for the coersion?

use Time::Piece;   # Core module
use Time::Seconds; # Core module

use constant TIME_FORMAT => '%I:%M%p';

my( $starttime, $endtime, $currenttime ) = 
  ( '9:01PM',   '3:30AM', '1:10AM'     );

# Create Time::Piece objects

my( $st, $et, $ct ) = map {
  Time::Piece->strptime( $_, TIME_FORMAT );
} ( $starttime, $endtime, $currenttime );



# Coerce end time to always be after start time.
# Coerce current time to always fall after start time (because time wi
+thout
# date is ambiguous)

( $et, $ct ) = map { $_ < $st ? $_ + ONE_DAY : $_ } ( $et, $ct );


# Now we don't technically need to verify that $ct >= $st, but semanti
+cally it
# doesn't hurt, and probably aids understanding of the algorithm, in c
+ase
# one wants to deal with the ambiguity of a missing date differently.

print $ct->strftime(TIME_FORMAT), " is ",
      ( $ct >= $st && $ct <= $et ) ? "in" : "out of",
      " range\n";
[download]

This reminds me of a bug that used to exist in the Buffalo LinkStation NAS firmware. The device could be set to turn off at a given time, and back on again at a given time. This seemed like a great idea to save power; have it do an incremental backup at 10:00pm, shut off at 01:00, and back on again at 08:00. But the bug was that setting a sleep time of 01:00 was seen by the firmware to be before the wakeup time of 08:00, and it would be rejected as soon as one clicked, "apply" because it didn't make sense to sleep a device that hadn't been awakened yet. Their bug fix was to allow sleep times of (for example) 27:30. Apparently testing hadn't considered this scenario, which is strange because it seemed like the most obvious use for the feature.