>>
>>I don't know about any of you, but I've been writing dates on cheques etc. as MM/DD/YYYY for the past year and a half at least. I've converted my self to writing a 4-digit year. If I was developing software that required date input in MMDDYY format I'd be forcing the users to do likewise. Right now, all the dates I'm using are julian for the day of the year only (don't ask!) At the moment I don't have anything that will roll over the EOY/EOC/EOM.
>>
>
>Our users have stated that they don't want to use 4-digit dates. That is the deciding factor for us. The users run the program. We build the program to their specs (when the specs make sense). Two digit years make sense, so we will be using two digit years.
>
>This is just our/my philosophy. When users are forced to do something, they may begin to resent things and generally have negative attitudes. Just another point of view...
>
>Joe

Nobody's forcing me.... I'm doing it myself.

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.

Jen