Re: Year 2000

On Sun, 5 Oct 1997, Guy Germonpre wrote: > June Tong wrote: > > Nils Myklebust (Nils.Myklebust@idg.no) wrote: > > : But I do believe ver. 4.x is as year 2000 compliant as anything except > > : for it not supporting the dbcentury environement variable. That is you > > : will have to show and key in years with 4 digits. Dates have allways > > : been represented the same way internally in Informix engines, so there > > : ought not to be any problem. Nils is correct; if the current year is 2000 or later, Informix 4.1x and earlier versions will (still) add 1900 to a 2-digit year. If you don't display all 4 digits, you may not be aware of this, which is likely to cause problems. > > If "year 2000 compliance" is defined as storing 4-digit years and not getting > > confused when the millenium hits, then yes, all Informix versions are "year > > 2000 compliant". The two things to be aware of with the older versions of > > products is lack of support for DBCENTURY (as mentioned above) and the fact > > that 2-digit years will be defaulted to 19xx, even after the year 2000. So I just repeated what June says, which was also correct. > > This means that if you say: > > INSERT INTO orders (order_date) VALUES ("11/11/11");> > You will get November 11, 1911, no matter what the current year is. Note this applies to the 4.1x and earlier versions (and the 6.0x versions) of I4GL and ISQL. 4.2x (on Unix, not the very old, DOS/Windows 4.2 I4GL) and 6.1x I4GL and ISQL will support DBCENTURY. > Then who is taking care of the translation between the internal stored > integers representing the year, The year is not stored internally as a separate datum; DATE values are stored as the number of days since 31st December 1899 (so 1st January 1900 is stored as 1). > and the actual understandable form of the year (05/10/1997 eg) ? It depends on the SQL statement. In the case shown above, the engine does the input conversion. In most I4GL programs, the I4GL libraries will do the conversion and pass the integer number of days to the engine. The output conversion will again be controlled by the SQL statement fetching the data; it might be the client side library (ESQL/C or I4GL, for example) or the server side library. Most usually, it will be the client side libraries. > I mean there was (is) a lot of confusion about if 2000 is a leap year or > not. Maybe there is confusion, but Informix has had the answer right all along. Just in case there's any doubt, the year 2000 is a leap year because of the 'divisible by 400' clause in the leap year rules. > Most OSses had/have this part wrong. Such as? Unix has had it right from the year dot (1970)? Yours, Jonathan Leffler (johnl@informix.com) #include <witticism.h>