> On Wed, 27 May 1998 08:36:17 -0600, "Gustavo A. Murillo Fuentes"
> > 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.
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
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
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
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 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
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
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
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
> Informix more than anyone else.
> Nils Myklebust
> NM Data AS
> FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html
> (Now with ODBC info under "Third party products".)