by
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? :)