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 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".)