Informix 4GL and year 2000 problems/ramblings

The year 2000 problem has not gotten very hot here and we've started to address our Informix 4GL concerns. 1) First of all, I've heard various things about DBCENTURY. I've heard it only applies to the engine and not the tools. I'm not concerned with the engine, I'm concerned with dates input from 4GL screens. The place to worry about which century is chosen is at the point of the user typing the data. At that point, the century is chosen and the date is converted to the Informix internal DATE type. If I decide to store the DATE variable in the engine, the variable gets stored as-is in the database. No century adjusting happens at this point because it's no longer a MM/DD/YY format, it's the internal format (# of days since 12/31/1899), with the century already chosen. I've heard DBCENTURY has no effect to any of the 4GL versions. Is this correct? I've heard one tool (was it?) esql/c 7.20 will use DBCENTURY. But, I'm not really doing input screens with esql/c. Don't know exactly what context it will use it in either. The date conversion function calls? Can anybody run down a list of exactly how and where DBCENTURY is used? 2) To become year-2000 compliant, we will be converting all of our forms to 4-digit years and include a FORMAT="MM/DD/YYYY" statement. This will allow 4-digit years to be keyed and displayed back to the user for visual verification. Yeah, this works, and it'll get us by, but it's not very clean. First of all, users are still going to type MM/DD/YY dates and 4GL still defaults them to the 1900's, (even if I set my clock ahead). And if the user isn't looking, they've just entered a 1900 date when they meant to enter a 2000 date. Step back from the developer's prospective and look at it from the average, everyday prospective. When you write down a date, do you write 12/07/1996 or 12/07/96? I use the DD/MM/YY format myself and I don't think the year 2000 is going to change that for the majority of the population. Users will still key DD/MM/YY and they're going to expect the computer to know what they meant. And that's something we as developers should be able to do for them. If it's an unusual date, (ie. an 1899 birthdate) then they can key all 4 digits of the year. In addition, keying extra digits is not a good solution. It forces more work and increases the possibility of typos. What if a user trys to key 01/01/2010, but keys 01/01/0210 or 01/01/2100? Now I've got to add all kinds of reasonability checking code (should be doing this anyway, I guess). 4GL is going to have to be able to handle 2 digit years better than turning DD/MM/YY into than DD/MM/19YY. Is there any way to do this? I've thought that maybe I could get the field buffer (get_fldbuf()) and look at what the user keyed to do my own date conversion (with DBCENTURY-like functionality added) but I can't seem to get the raw-user input, only the post-formatted result. Also thought about redoing the date fields to formonly CHARs and writing my own date conversion routines. Really don't want to have to do this, but right now it may be the best solution to provide a solution to a problem Informix wont address. 3) As I've stated in an earlier post, even if DBCENTURY is available to 4GL, it's unacceptable because it's an environmental variable. In other words a "global constant". Such a thing is not suitable for all all applications. One application may have a variety of dates, like employee birthdate (always in the past). The same screen may have retirement date or review date (future). Other fields may need the "closest" logic. If Informix will provide something to set the default on demand, great! Something like: BEFORE FIELD birth_date CALL set_dbcentury("P") # past (closest previous year) BEFORE FIELD retirement_date CALL set_dbcentury("F") # future (closest future year) Yes, we'll have 4-digit year screen fields, but as in issue #2 above, the problem isn't entering and displaying 4-digit years, it's allowing the user to enter MM/DD/YY (as I believe they will prefer to do) and guessing correctly what they meant. -- __________________________________________________________________________ Joel Schumacher JCPenney Co. - UNIX Network Systems jschumac@uns-dv1.jcpenney.com 12700 Park Central Pl (972) 591-7543 Dallas TX 75251