Re: Y2000 and 29/02/00~v

On Thu, 30 Oct 1997, Helmut Leininger wrote: > Jonathan Leffler wrote: > > > If you are using a two digit year with DBCENTURY set to C and try and > > > insert the date 29/02/00 you will get a 1204 - Invalid year in date. > > > > I can confirm that for OnLine 7.23.UC1 on Solaris 2.5.1. > > Same on AIX. That makes it a generic bug. Jack Parker also confirms that it's a problem, though he's not sure whether it is in the tools or the engines. Since I used SQLCMD (effectively DB-Access) and the SQL code below, I'm convinced that this is a bug in the engine, though it will probably also affect the date conversion routines in ESQL/C since they use the same source. CREATE TEMP TABLE d (d DATE NOT NULL); INSERT INTO d VALUES("29/02/00"); -- Error INSERT INTO d VALUES("28/02/00"); -- OK INSERT INTO d VALUES("1/03/00"); -- OK > > Not in my book. The error message doesn't make sense. I stand by this comment. > > Invalid day in date would be explicable -- the conversion to 4-digit > > year was taking place after the leap year check. I suppose it could be > > that they are taking the 2-digit year (00) and treating is as a 4-digit > > year before doing the addition; then it is an invalid year (there was > > no year 0; it went 1 BC to 1 AD). I think this explanation (which I wrote, I hasten to add) is rubbish. I shouldn't have made any attempt at explaining the inexplicable. > This does not seem to be the case exactly. The year 00 (meaning 2000) is > accepted. It accepts also "00/02/28" (DBDATE=Y2MD/". I think the mistake is > that all years xx00 are *no* leap years except if the century is a multiple of > 4 - and Informix seems to do the leap year calculation before adding the > century ("2000/02/29" is ok). That's roughly what I meant, but not what I said. Yours, Jonathan Leffler (johnl@informix.com) #include <witticism.h>