Update: Congrats on your homework score, and thanks for telling us up front. ;)

1. Don't use POD to store test data. Instead of =item test, consider putting test data under a __DATA__ token at the end of your sources. Or if you're disabling a section of code and want to use POD, use the proper POD tags to disable compilation. =item isn't always seen as a proper beginning of a POD chunk.

2. Completely optional, but I would put a call to exit() before you start defining subs. If I don't see one, I start looking for extra mainline code between and after all the subs.

3. Pick a capitalization style for subroutine identifiers, and stick with it. Your format_time is Perl standard, but CheckRanges is different.

4. Minor note about your #-- END foo sub-routine comments. If I can't see both the top of the sub and the bottom of the sub on a large screen (or with fewer than two page-ups on an average screen), it might be too long. Consider how the task can be naturally divided. These are short subs, and the indentation is mostly consistent, so I wouldn't bother with these closing comments.

5. Dennis and Kernighan (of C fame) fought this battle too, but consider putting a space after keywords like for (...) and return (...). If it doesn't have a space, it looks like a subroutine identifier, and for is not a function.

Check perlstyle for more general Perl style ideas.

--
[ e d @ h a l l e y . c c ]

Or if you're disabling a section of code and want to use POD, use the proper POD tags to disable compilation. =item isn't always seen as a proper beginning of a POD chunk.

While I agree with part 1, part 2 is untrue -- stick to properly formed pod, like

#hey some code followed by a blank line

=butter is the pod, and the pod is the butter

=cut followed by a blank line, no more pod

#and here we have some other code
[download]

Even if use fictional pod tags, perl will parse it correctly. You should stay away from hidden pod/code, as the behaviour is not guaranteed in future versions (see Pod::Stripper, perlpod if you don't know what it is).

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

I agree.

As with Perl syntax, perl will parse a lot of POD constructs which other tools just don't bother to try to read properly. This has been improving, but there are a lot of different tools, from formatters to text editor modes.

--
[ e d @ h a l l e y . c c ]

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Just curious -- what would you recommend as an alternative to the global "%w" hash used for holding widget handles in the OP?

I've been known to use this same approach myself for self-contained Perl/Tk apps of similar size (even larger) -- a global hash that holds all the widgets makes it easy to access any given widget from within any given callback subroutine, and this is handy when the callback for some widget or bound event has to reconfigure one or more other widgets, which might be anywhere else in the GUI.

Given sensible hash key strings, this seems easy enough to maintain (and to "add features" or change the app's behavior later on, when needed). So, I know globals are "naughty" for various good reasons, but they can be a viable option -- they do have their place, I think.

If there is a better way (without the global hash) in such a case, I'd be grateful to see it. (I come here to learn stuff like that.)

There are cases where globals are fine, especially in smaller apps.

A common way to do a "global variable" is to use a Singleon. I would recommend using Class::Singleton vs. rolling your own, but the basic idea is:

package Dragonchild::Singleton;

my $singleton;

sub new
{
    my $class = shift;

    $singleton ||= bless {}, $class;

    return $singleton;
}
[download]

No matter how many times Dragonchild::Singleton->new is called, the exact same variable is returned. It's partially a style issue, but I prefer singletons over our'ed variables. Other monks will tell you the opposite. TMTOWDI

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Congrats on "use stict;" - I'd also 'use warnings;" (or -w on the shebang line).

Nits: instead of:

  $time{month} = 'Dec';
  $time{day} = 12;
  $time{year} = 2003;
  $time{hour} = 14;
  $time{minutes} = 0;
  $time{seconds} = 0;
[download]

%time = (
    month => 'Dec',
    day => 12,
    year => 2003,
    hour => 14,
    minutes => 0,
    seconds => 0,
);
[download]

(The => operator takes care of stringifying what's to the left of it.)

Consolidating the globals (as in %w) is a good thing, though minimizing their use is beter, as others have said previously.