Re: Y2K Issues in Informix

Hi all, Whenever you are answering to this type of queries then Instead of just copying from the Informix Manuals, we would appriciate small but neet and precise answers. Some time it might be a misguidence to all Informixities. Here point is not underestimate any one but just thought came into mind, I think it is useful to all of us. Thx girish >Date: Wed, 27 May 1998 19:31:55 -0700 >From: Varadharajan M Kope <mkv@infogain.com> >Reply-To: mkv@infogain.com >To: informix-list@iiug.org >CC: Nils.Myklebust@nmdata.com >Subject: Re: Y2K Issues in Informix > >Sorry made a mistake. But it does NOT change the result. > >DBCENTURY = F ( Consider present and future century. Chose future date. >If both the days are in future, chose the future date closest to the >current date ) > >* Date of Birth = 1/1/2049 and 1/1/2149 Future closest date is >1/1/2049 stored as 2049 > Date of next increment = 1/1/2001 and 1/1/2101 Future closest date is >1/1/2001 > DBCENTURY = F will not work for date of birth > >..mkv > >Varadharajan M Kope wrote: >> >> 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 th