RE: Year 2000 Impact on Informix -Reply

>>> Scott Black <sblack@elsouth.com> 04/24/97 12:57pm >>> At first I was going to tell you about Informix 7's method of dealing with this and that it was not much of an issue. But then I got to thinking about it and I'm not sure how SE 5.0 deals with it. Our main box runs Online 7 and the environment variable takes care of all of our problems but we also have another box which runs SE 5.0. So I wonder what the implications are for this particular installation? Thanks in advance for any help on this. The simple fact is that the database itself has *never* had a problem with the year 2000. The database engine stores dates as integers representing the number of days since 12/31/1899, and thus is able to handle 2,147,000,000+ days forward or backward of this date. Applications, however will have problems if they allow only two-digits for the year, because the user cannot specify what century a date is in. The newer engines (i.e., 7.x) allow setting an environment variable as a default century, but this only circumvents the problem of a date defaulting to a 20th century year (as would happen with current apps using 2 digit years in their date fields. The long and short of the problem is: First, use only 4 digit year fields. Tell the users that is the length of the field required, never compromise on that. Second, upgrade to a 7.x+ version engine that uses the date environment variable so that your apps can default the year to the current century for users without them having to input all 4 digits of the year without any specialized programming. This allows the date field to act as it does now. If you don't upgrade to a newer engine, the app won't break if rule #1 is followed. Users would have to type a 4 digit year, though, unless there is some customized logic in place. This "problem" is in reality no more than an inconvenience. Consider the seriousness of year 2000 problems with other software installations. Tim P.S. Did I mention always use a 4 digit year? :)