I attended a payroll software demo yesterday wherein the year dropdowns throughout the software ran from 2000 to 2200. Now, we've all been down this road before with 2 digit shortsight, but honestly - a 200 year service life for a Java & Oracle payroll system? Our Board of Directors would be thrilled if the company was even solvent for 1/4th that long.
When forced to use a dropdown year select, where do you draw the line?
It depends upon the usage. If you're trying to ascertain retirement dates for financial planning, you need to allow users to select years decades into the future. If you're asking for credit card expiration dates, current year + 10 should be more than sufficient. Either way, you would be populating these dropdowns dynamically, lest you desire touching up the user interface every year.
Why not make your app end-user-configurable? Give them a config screen, let them enter a cut-off year as 4 digits and refer to that in the code?
I like to make as much as possible end-user-configurable - it means I can ship one s/w to multiple customers, and it pushes off some tricky decisions to them :-)
The drawback of such a large range is that the dropdown becomes unwieldy - there will certainly be a scrollbar, and it becomes harder to find the year you're looking for.
If it has to handle retirement dates, I'd say 55 years into the future would be sufficient (an 18 year old will probably be retired by 73). My limited experience with such systems precludes me from knowing what a reasonable limit would be otherwise - perhaps you can enlighten us?
Who's forcing you to use a dropdown year select? They're annoying as all hell.
Do a research project showing that typing in a 4-digit date takes less time than using a pulldown big enough to have a scrollbar, multiply the time difference by a vastly inflated estimate of how many people will be using the software, multiply that by a vastly inflated estimate of the pay rate for data entry, and show the company how you can save $18.7 billion over the life of the software.
