First, Adam, thanks for the great link.  I took a look at ALL of the scripts including the additional reference to the auxiliary number table and I definitely see your point and the case for an auxiliary date table is a powerful one.  So powerful that I'll relent and admit that dedicating the necessary disk space is well worth the investment of disk space and the, apparently, very minor maintenance of adding additional years.  This is proof that even an old dog can learn new tricks!  Thanks for your patience and your posts on this thread.  A lot of other people would have lost their cool or just given up.

Just a note, I did some very rough calculations to see what would happen if the auxiliary date table they suggested is setup for 30 years. Each row takes up only 28 bytes (only 1 byte for the two BIT data types, could get 6 more bit columns for “free”).  Even if you tripled that size to account for the overhead of VarChar fields, the “Null Bitmaps” of fixed length fields, and the index, etc, that would only be 84 bytes per row or 30660 bytes of storage per year.  30 years would still be under a megabyte which is a pretty darned small table nowadays. 

I’ve gotta take back what I said about auxiliary date tables and say they’re very well worth setting up.  I’ll eat the crow later, when I've finished cooking it up with extra garlic and a side of humble pie.

Oleg, thanks for the great follow-up.  I haven't tested what you suggested but, based on your explanations and looking at the code you posted, it’ll probably work.  Considering that I’m probably going to setup my own auxiliary date table, I probably won’t get to testing your suggested alternate code.

Hey Everybody!  Thanks again for all of your responses.  They were great and I think I learned more than what I thought I was teaching.  Like I said, that's one of the reasons this forum is so great!