Re: Informix 4GL and year 2000 problems/ramblings

Hi, This is long and complicated, but I hope worthwhile. Joel Schumacher's original question is prefixed with JS. Billy Wheeler's comments are prefixed BW. I haven't prefixed my comments. >From: jschumac@uns-dv7.informix.com (Joel Schumacher) >Date: 8 Dec 1996 00:52:01 GMT >X-Informix-List-Id: <news.31357> >From: "Billy Wheeler" <billy@west.co.za> >Date: Sun, 8 Dec 1996 08:40:12 +0200 >X-Informix-List-Id: <list.12331> JS: The year 2000 problem has not gotten very hot here and we've started to JS: address our Informix 4GL concerns. JS: JS: 1) First of all, I've heard various things about DBCENTURY. I've heard JS: it only applies to the engine and not the tools. I'm not concerned JS: with the engine, I'm concerned with dates input from 4GL screens. No currently available version of I4GL supports DBCENTURY. I am reasonably reliably informed that the next version but one (4.18/6.06) should have support for DBCENTURY, but since that is still a future product, it needs to be treated with a small pinch of salt. I think it is reasonable to predict that before the end of 1999, there will be a version of I4GL with DBCENTURY support:-) BW: Now I'm confused. How is DBCENTURY going to do anything if it only BW: gets used by the engine? DBCENTURY is of use in the engine is a character string is converted to a data and the string has two digits for the year -- then the string is converted using the DBCENTURY rules: Eg: INSERT INTO SomeTable(DateColumn) VALUES('12/31/99'); # DBDATE=dmy4/ BW: My current understanding of DBCENTURY is BW: that you can set it to be a specific century or the century closest BW: to the system date and it works for all tools. Hm, maybe not! :-) Not quite, and no. As has been summarised previously, you can set DBCENTURY to 4 valid values plus all the invalid ones. The four valid values are 'F', 'P', 'C' and 'R'. 'F' means future. All ambiguous (2-digit) years are placed into the future, based on today's date. If today's date is 1996-12-08 and DBDATE is 'dmy4/', then entering '9/12/96' will convert to 1996-12-08, and entering '7/12/96' will convert 2096-12-07. Empirically, it turns out that '8/12/96' is treated as '2096-12-08' (to ensure it is in the future). 'P' means past. All ambiguous years are placed into the past, based on today's date. Given the same current date and the same three entries, the dates entered are 1996-12-07, 1896-12-08, 1896-12-09. 'C' means closest. All ambiguous dates are placed closest to today's date. 'R' means present century. All ambiguous dates use the current century. (I know; I set my system's clock to 2006-12-08 to see what happens, and all three trial dates are set to 2096). DBCENTURY unset or set to an invalid value is equivalent to DBCENTURY=R. JS: The place to worry about which century is chosen is at the point of JS: the user typing the data. At that point, the century is chosen and JS: the date is converted to the Informix internal DATE type. Absolutely correct. The place to worry about it is when the string the user types is converted to a DATE value, which, in I4GL, is generally when the user exits from the field in which the date is typed. JS: If I decide to store the DATE variable in the engine, the variable JS: gets stored as-is in the database. No century adjusting happens at JS: this point because it's no longer a MM/DD/YY format, it's the JS: internal format (# of days since 12/31/1899), with the century JS: already chosen. Also correct. JS: I've heard DBCENTURY has no effect to any of the 4GL versions. JS: Is this correct? BW: It might be true, although I'm sure they'll fix that soon enough... See my comments above. JS: I've heard one tool (was it?) esql/c 7.20 will use DBCENTURY. But, JS: I'm not really doing input screens with esql/c. Don't know exactly JS: what context it will use it in either. The date conversion function JS: calls? ESQL/C 7.2x provides DBCENTURY-aware calls to convert strings to DATE values. JS: Can anybody run down a list of exactly how and where DBCENTURY is JS: used? DBCENTURY is used when a DBCENTURY-aware string-to-date conversion function is called to convert a string with a 2-digit year. JS: 2) To become year-2000 compliant, we will be converting all of our forms JS: to 4-digit years and include a FORMAT="MM/DD/YYYY" statement. This JS: will allow 4-digit years to be keyed and displayed back to the user JS: for visual verification. Yeah, this works, and it'll get us by, but JS: it's not very clean. You MUST display 4-digit years to be unambiguous. This has always been true. Birthdates extend back to the 1800's; mortgage maturity dates extend forward into the 2000's. This has been true for a long time. The only facility that DBCENTURY provides is a more convenient shorthand data entry mechanism. JS: First of all, users are still going to type MM/DD/YY dates and 4GL JS: still defaults them to the 1900's, (even if I set my clock ahead). JS: And if the user isn't looking, they've just entered a 1900 date when JS: they meant to enter a 2000 date. BW: This is exactly what DBCENTURY is supposed to solve. And does... JS: Step back from the developer's prospective and look at it from the JS: average, everyday prospective. When you write down a date, do you JS: write 12/07/1996 or 12/07/96? I use the DD/MM/YY format myself and JS: I don't think the year 2000 is going to change that for the majority JS: of the population. Personally, I write either 1996-12-07 or 07-12-96; and once the century changes, I'll be writing 2001-01-01 uniformly because only that it unambiguous. JS: Users will still key DD/MM/YY and they're going to expect the JS: computer to know what they meant. And that's something we as JS: developers should be able to do for them. If it's an unusual date, JS: (ie. an 1899 birthdate) then they can key all 4 digits of the year. BW: Yes. And, in general, DBCENTURY allows that to work. JS: In addition, keying extra digits is not a good solution. It forces JS: more work and increases the possibility of typos. What if a user JS: trys to key 01/01/2010, but keys 01/01/0210 or 01/01/2100? Now I've JS: got to add all kinds of reasonability checking code (should be doing JS: this anyway, I guess). Yes, you should be doing plausibility checking for 0210 as a date; likewise 2100. You can, and probably should, have a selection of checking routines which can be called in the AFTER FIELD clause of an INPUT statement. One of these could verify a birthdate. For many commercial applications, this could be required to be more than 10 years in the past as many (but by no means all) commercial applications are not concerned with children. Similar checks can be required to ensure that mortgage maturity dates are in the future. These routines can correct some date values, and require confirmation of others, and so on. JS: 4GL is going to have to be able to handle 2 digit years better than JS: turning DD/MM/YY into