Re: 96096, Feb 29 bug
On Wed, 5 Aug 1998 Kate_Tomchik@homedepot.com wrote: > Okay guys, I know everyone argued that this wasn't a problem at the > conference, but this bug is still open and it implies that no version of > Informix has the Feb 29 problem fixed for ESQLC. I called the support > line again today and got the same response. Can someone correct me if > I'm wrong by telling me which version of the engine/esqlc has this fixed? PTS bug number B96096 was opened on 18th June 1998, which is very recent indeed. The bug is reported in the QA test suite, so it isn't clear what the problem really is, especially as the description is, to be polite about it, minimal -- Y2000 QA_DIFF -D OPTION FAILED TO WORK WHEN DATE IS 02/29/2000 BECAUSE IT IS TREATED AS INVALID DATE. SDK201 There is no further information in the database for this bug, so I hope someone else can decipher it, because that doesn't tell me very much. The canonical bug in this category is B60150: EVEN WITH DBCENTURY SET "02/29/00" IS TREATED AS AN INVALID DATE. B60150 is fixed in some versions of the product, including 7.23.UC9, 7.24.UC4, 7.30, and ClientSDK 2.01 (aka ESQL/C 9.14.UC1). Interestingly, it doesn't seem to have been a problem on NT. I also just verified that ClientSDK 2.01 is fixed, using the code: #include <stdio.h> int main() { long d; int i = rdefmtdate(&d, "dd/mm/yy", "29/02/00"); printf("i = %d, d = %d\\n", i, d); return 0; } With DBCENTURY set to C or F or P, this generates error -1204 (invalid year) under 7.24.UC1, and -1206 (invalid day) with DBCENTURY set to R. The results for C and F are wrong (that's the bug), but correct for R and debatable for P (the date is invalid because 1900 was not a leap year, but invalid year is not the best error to give). Under ClientSDK 2.01.UC1, it generates -1218 for DBCENTURY set to R or P (current century or past), and no error for DBCENTURY set to C or F (closest or future) -- both of which are correct. So, yes, some versions of Informix products do have a bug in the DBCENTURY handling. Some versions of the products have this fixed. Bug B96096 is not a good one to track -- B60150 is much better. If anybody happens to know anything more about the cause of B96096, please let me know. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.59 -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn