>>The hedge is to consider that any before about the 18th century may be invalid. The Gregorian Calendar wasn't introduced until the 17th century, and wasn't completely in use in the Western World until sometime in the 18th. So the validity any date before that time could be questioned. What a way to start a Friday.:-)
>
>I see your point -- might be best just to catch as invalid any date before whatever year is reasonable in your specific app, not just 0s...

Exactly, Bruce. When dealing with dates it's important to consider the context. In my job, the date something was produced, can't be greater than the current date. The day something is to be shipped, shouldn't be entered as less than the current date. For other dates, such as a birthdate of a living person, there's a reasonable range that can be established. So in these cases, it's fairly easy to "cover the bases".

Others, however, aren't so simple. Dates connected with financial transactions, might have a 5-7 year range (auto loan) or 30 year (mortgage, bonds) range. Still, this is doable. A table with historical data might present considerable problems (how do you "date" antiquities?), however. Nevertheless, when designing the class, it's (in my mind) imperative that the context in which a date entry is to be applied be taken into consideration at the beginning, and not as an afterthought.