Mostly, I was thinking: why does everyone want to reinvent wheels when learning? Why not find a wheel and augment it?

The process of augmentation will mean you have to understand the code and the rest of us get the benefit of an improved module.

You say your module has features above and beyond Time::Duration. So patch TD. I'm sure Sean would welcome your patch. Think of it as an exercise in community development.

As for the code: As belg says, look to something like Class::Accessor to obviate that nasty infection of identical accessors. I'd argue against using AUTOLOAD to create accessor. Something like chromatic's loop is much better.
You seem to do a lot of calculation when anything is changed, rather than just when people want things. I'd like to comment more, but your main problems are in your todo list - items 1, 2 and 3. POD is well covered by perldoc perlpod. Tests, you've been given a pointer, and there's an excellent section in "Learning Perl Objects, References and Modules", merlyn's new book. Comments you just need to make the code clearer. It's hard to read with all the references you're using (and, as they're references, you can assign them to temporary variables which (as they're references) affect the original when you modify them). I can't quite see where you work out how long a month is (a fun thing since it varies according to when your period starts). As far as I can tell, it's one of those hard coded large numbers. (sidenote: 31_536_000 is valid perl: the underscores are ignored). You take _is_number from Scalar::Util. Why? It was happy there. You should access your internal bits via methods rather than direct hash access. Makes it easier when I want to write my subclass, and means you can stave off calculations until the methods are invoked, rather than needing calculation up front to make sure that the hash values are always right (well, until I reach in and modify one and they're all wrong).

The general thing is that when code is appropriately commented, documented and tested, if it does what it's meant to do, it's good. Just like the rest of cpan (ha!)

Over the years CS has solved many problems. Many, many problems.

Yet everyone insists on solving them afresh. Often not even knowing they've been solved. Sometimes, when previous solutions are pointed at, they claim "I was doing it to learn". This begs the question: to learn what?

To learn how to write a module? Well, that's fairly basic, and the ancestor node of this post failed if that was their intention. No POD, no tests, ergo useless. Perhaps it's an attempt to implement an algorithm. Again, with no tests, how do you know it's working? Aside from a lack of tests, what is new about it? How does it differ from the other implementations around? Was any research done as to what would be a good way to implement it or was it from the top of one's head?

The world is full of documented algorithms and approaches. It's full of libraries that implement all sorts of things. If you ignore CS, you are doomed to reinvent it, and often badly. And not only that, just think what you could be doing instead. You're effectively dragging down the community when you could be contributing to something and making things better.

A splendid example is the CGI.pm module. It parses query strings correctly. Now, we've all seen hand rolled query string parsers, and they rarely get it all right. How many of them understand the ';' notation that one can use instead of '&'? How many of them have problems if a key is specified multiple times? People looked at their browsers and saw what they passed their programs. They looked at their programs and saw what they were given. They probably assumed this was the complete range. Did they consult any RFCs? Did they check the CGI.pm source? Did they look in the source for any CGI libraries for other languages? Probably not. Did they have a good reason to not use CGI.pm? Probably not. Is their version inferior? Definitely.

People forget that CPAN is a vast resource for learning. There's a lot of good code out there. There's also a lot of bad code. It's amazing the value of studying bad code and going "Even I could write that better" and then doing so. Looking at the good code is also good. You can see what they're doing, or try to work out what they're doing and why.

If you don't do research, how can the art be expected to progress? Are we fated to forever be writing btree and hash implementations from scratch without reference? Or worse, stuck with lots of programs using straight indexed arrays rather than a more efficient structure for no good reason other than not knowing any?

At a university, you'll study the common data structure and algorithms. Even more amazingly, you aren't expected to just come up with them. You're expected to research. Or maybe your lecturer will just give them to you. In later years, you'll be asked to do things like implement red black trees (for example) and you'll certainly be expected to research. Maybe you'll come across other interesting and useful algorithms while you're researching. At the very least, you'll learn how to research if you haven't already.

Read magazines regularly. Read perl.com articles. Subscribe to tpj.com. Subscribe to safari.oreilly.com and rent books you'd never pay cover price for. Read journals of societies such as ACM and IEEE. Any decent university library should have an archive of the older issues and these are often just as relevant as the newer ones. Further your art.

It all comes down to one of the truly important aspects of being a programmer: being able to think. In order to think well, you need input. Do research. You'll learn more.