>
>Actually, for most of the time it makes sense to default to the current century. For example: I'm entering payroll data. Period from date = 121599, period to date =123199, Check date = 010800 (we're paying every 2 weeks & running a week in hand). You can do this with a 2 digit displayed date as long as you get a little clever. You know what century you're in from the system date. (OK, that's an assumption, but we gotta start somewhere!) You also know that the 3 dates run in sequence: from, to, check. From these 2 pieces of information you can work out that the from & to dates should be 1999 and the check date should be 2000, simply by checking which comes first. If the check date is 010800, then the from and to dates cannot refer to 2000, as they must be earlier than the check date. You don't even need any date routines, convert them to integers as YYYYMMDD and see which is bigger. 20000108 is larger than 19991231....
>
>Am I missing something horrendously obvious or is most of the Y2K fuss about poor programming methods and bad assumptions? It's a problem if you have a 6 digit date field, but with an 8 digit date field, there should be no real problem unless you are dealing with isolated dates and the users insist on entering a 2-digit year.
>

Well, some systems do not store the century part of a year. So there is NO straight forward way to differentiate between, for example, 2000/01/25 and 1900/01/25. This is often a flaw with the language/development platform.

The example that you gave shows a specific bit of data that has a specific relationship (d1 <= d2 <= d3). That require hard-coding for this bit of data. Well, if this data entry screen was developed in the mid-80's, the programmer may not have been concerned with the Y2K issue so this is something that, now, has to be detected as a problem and solved. The code to fix the problem is not the problem. Finding all the problem code is the problem.

The best solution (IMHO) is the one that VFP has implemented which is the use of a rollover year (a rollover year that can be modified). With this method, the only hard-coding required is in a situation where a date falling out of the 100 year span might be entered. If you trap a keystroke (Alt-4?) in your date entry textbox class and change the format of the field to a 4-digit year, your problem is solved.

With the ROLLOVER feature, what is your resistance to 2-digit dates?

Also, another example of where Y2K problems can exist (there are hundreds): A registration number must be generated. The 2-digits of a year is to be used somewhere within the registration number. In 1983, the programmer didn't think about the Y2K problem and just used the formula YEAR-1900 (eg. 1983-1900=83) to get the two digits. In the year 2000, that will give three digits which could cause an overflow or other problems. Hey, don't look at me. I was in high school in 1983. But in 1983, when a programmer was being pushed to get a system done, do you think he/she was really thinking about Y2K?

Joe