Without a doubt, data input fields will be the most common area for finding potential Y2K bugs. Not many forms that I’ve seen require the user to enter four-digit years. In fact, in my experience, users will simply not stand for having to enter four-digit years.
You can solve this problem in one of two ways. Either you can write a function that will internally convert the user input to a four-digit year, or you can insist that all dates are input with four digits for the year.
Any function that you write to convert user input to a four-digit year will at some time need to guess the required date. It is impossible to know for sure what a user’s intention was when he or she entered data into a date field. How is the application to know that 01/01/00 should be interpreted as January 1, 2000, and not January 1, 1900? As I said, you can guess the intentions, but you can’t be positive. With this in mind, I would opt for the second solution: forcing the user to enter a four-digit year in all date fields. This choice might not be popular with the users, but I’m sure that a system crash on their return to work after the New Year’s holiday in the year 2000 would be even less popular!
So produce a list of all input fields within your application that accept a date from the user. Bear in mind that it’s not only date fields that can accept date input. Many applications use calendars to accept dates from the user. If your application uses a calendar utility, you should list this utility along with the list of date data input fields.