Re: What happen Informix? - Y2K Issues in Informix

Nils Myklebust wrote: > > On Wed, 27 May 1998 08:36:17 -0600, "Gustavo A. Murillo Fuentes" > <gmurillo@gotec.com> wrote: > > > > > > > One company of software in Costa Rica, associated with Oracle, say without > >problem: "We are created one tool for migration since the obsolete Informix > >tecnology to Oracle tecnology" and they suggested between lines, what > >Informix 4GL have problems with the Y2K!!!. What happen Informix? :-( > > 1. There are no Y2K problems with Informix 4GL appart from those you > created yourself by using only 2 digts for years in input fields. Even > these are solved by Informix in ver. 4.20 and 7.20 of 4GL via the > DBCENTURY environement variable. I would assume this company have done > something similar. > Right from the day I started writing any date, I have always used 2 digit years. This was the CONVENTION. Naturally, most of the programmers have used 2 digit years in their code and system design. So we may not have used 4 digit year in screen or reports. These may be problems created by us but let us not kid ourselves. That DBCENTURY will take care of everything may not be entirely true. Most of the applications, yes. But applications which deals with date which spans more than +-50 years could pose problems. This may or may not be likely in many applications and you are the best judge regarding your application. Informix does not have any problem in storing dates that belong to different centuries. But the problem is what happens when we cross the year 2000 with 2 digit year all over in my application. Informix gives you DBCENTURY environment variable which can have values F - Future, P - Past, C - Closest, R - Current century which is the default. Let us say if you are having screens which accept 2 digit dates for some thing like a date of birth ( past date ), date of next increment ( future date ) (when compared to the current date). Suppose the values are as follows : Date of Birth = 1/1/49 ( 1949 ) Date of next increment = 1/1/1 ( 2001 ) Current Date = 3/ 1/ 00 ( 2000 ) DBCENTURY = P ( Consider past and present century, Chose prior date ) Date of Birth = 1/1/1949 and 1/1/2049 Prior date is 1/1/1949 * Date of next increment = 1/1/1901 and 1/1/2001 Prior date is 1/1/1901 stored as 1901 DBCENTURY = P will not work for date of next increment DBCENTURY = F ( Consider present and future century. Chose future date ) * Date of Birth = 1/1/1949 and 1/1/2049 Future date is 1/1/2049 stored as 2049 Date of next increment = 1/1/1901 and 1/1/2001 Future date is 1/1/2001 DBCENTURY = F will not work for date of birth DBCENTURY = C ( Consider past, present and future century. Chose closest date ) * Date of Birth = 1/1/1949, 1/1/2049, 1/1/2149 Closest date 1/1/2049 Date of next increment = 1/1/1901, 1/1/2001, 1/1/2101 Closest date is 1/1/2001 DBCENTURY = C will not work for date of birth DBCENTURY = R ( Consider present century. Chose current century date ) * Date of Birth = 1/1/2049 Date of next increment = 1/1/2001 DBCENTURY = R will not work for date of birth Note that we can not be flipping environment variable between different data entry screens. Now the problem is clearly applications which deal with dates > + or - 50 years from current date using 2 digit years. In this case year 49 falls outside the 50 year boundary. Hence same DBCENTURY setting may not work for all date columns in your application. The simplest solution is USE 4 DIGIT YEARS, so that Informix knows which year without having to interpret using DBCENTURY. Now this means, we have to look at screen layout to see if we can accomodate 4 digit year during entry and CHANGE it. Reporting may not be a problem, since we have the common sense to read a 2 digit year on print and interpret the correct century. Data transfer between external systems may also pose a problem and require CHANGE. If we are not changing to 4 digit years, with any of the above DBCENTURY setting, we can take care of about half the dates as 2 digit dates, but we may have to code some logic to interpret the correct century for the others. For example, I could leave DBCENTURY as Current/Closest and put some code in after field clause of Date of Birth. This means CHANGE in application. For date values stored in character or smallint fields it is totally a different story. It is like COBOL. I have seen atleast one such Informix application. THIS PROBLEM MUST EXIST IN ORACLE TOO. There may be tools. But we also have tools for Informix or atleast develop if we do not have. We are developing some tools for analysis and conversion for fixing Y2K problems. May be Informix can provide a better fix. A SET CENTURY statement may work which I can plug in for some problem date fields. But this may lead to other problems after a certain date ( standard windowing technique). We should think about this Y2K problem to see if we can arrive at a better solution and propose to Informix. May be Informix folks have already given it too much thought and had arrived at this DBCENTURY as the best fix. We represent the Informix world and we really need to provide good suggestions. I would sincerely recommend changing applications to 4 digit years if there are problem date fields. May be, we need to have a NEW CONVENTION, read and write 4 digit years. If my above interpretation of DBCENTURY is wrong please correct me. I have tested the above values by resetting system clock and doing insert with different DBCENTURY settings using dbaccess and then did a select with DBDATE set as DMY4. And that is how the values got stored. I had used 7.22 UC1. Actually I had done this long time back when the feature was announced. I will have to test using the latest version of 4GL, IDS and ESQL/C to see if it is any different. Has any one tested using 4GL and ESQL/C already ? Thanks & Regards ..mkv > All in all an interesting development that if handled well may benefit > Informix more than anyone else. > > Nils Myklebust > NM Data AS > Norway > E-mail: Nils.Myklebust@nmdata.com > FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html > (Now with ODBC info under "Third party products".)