These routines are quite efficient and yet are always guaranteed to agree with localtime() and gmtime(). We manage this by caching the start times of any months we've seen before. If we know the start time of the month, we can always calculate any time within the month. The start times are calculated using a mathematical formula.

So the only thing I could see that would make it slower than your method is the fact that it validates the input before acting on the data, which you can turn off using the timelocal_nocheck option and of course the fact that methods are always slower than subs which are always slower than inline code.

Ok - now that little nit is over, it is almost always turns out that to improve the speed of a giving piece of code to add caching (if possible) or change the algorithm.

As far as optimizing a piece of code being fun and interesting - I quite agree. You should be using Devel::Profile to determine exactly what piece of the code is chewing up time and focus there as it will often not be where you think the problem is. You should also always Benchmark on an idle system. Your test data should be thoroughly varied as "real" data can often swing your results in the other direction. By that I mean that comparing index to a regex might be slower for strings up to 30 characters, but then it may take the lead and ultimately demolish the regex. If you haven't taken that into account in your test data, you will still end up with poorly optimized code.

Optimized code that isn't the result of a new algorithm or caching is almost always harder to maintain. I have such a piece of code that I not very proud of even though it gets the job done. It is better to learn the better algorithms than make your code unreadable. If you absolutely need that much speed and can't get it from better algorithms/caching - maybe it is time to learn a new language.

Cheers - L~R