ESQL/C dtcvfmtasc()
JLK62 found dtcvfmtasc() with a two-digit year failed for 29 February 2000 on ESQL/C 7.22.UC2 against IDS 7.30.UC2 (SCO OpenServer), with DBCENTURY set to C. Jonathan Leffler said older versions such as 7.22 likely had a bug (B65050 or 69050) with implicit-year conversion, done in the client library, so upgrading ESQL/C was needed. An earlier 1999 date slip was corrected.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
After having found that certain versions of Informix (both SE and IDS) don't support the leap year date (Feb 29, 2000), I upgraded IDS to version 7.30.UC2 (SCO Openserver). I can now see that the leap year date works. However, to insert a date/time doesn't - using the following: dtcvfmtasc("022999 000109", "%m%d%y %H%M%S", &date_time_varaible) fails. My version of ESQL is 7.22.UC2. I'll look to upgrade this (if possible), but I was wondering if anyone else had come across this? Thanks. Joe
JLK62 wrote: > After having found that certain versions of Informix (both SE and IDS) don't > support the leap year date (Feb 29, 2000), I upgraded IDS to version 7.30.UC2 > (SCO Openserver). I can now see that the leap year date works. However, to > insert a date/time doesn't - using the following: > > dtcvfmtasc("022999 000109", "%m%d%y %H%M%S", &date_time_varaible) > > fails. My version of ESQL is 7.22.UC2. I'll look to upgrade this (if > possible), but I was wondering if anyone else had come across this? Since the implied year is xy99, and xy99 is never divisible by 4, I don't see how you would expect the date to convert without error? Specifically, there was no 29th of February in 1899 or 1999, nor will there be one in 2099 unless the rules change between now and then. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN #include <disclaimer.h>
I'm reposting to make a correction to my original post (I accidentally put the date in as '99' instead of '00' - which has been pointed out by many a person on this list that 1999 is not a leap year, but 2000 is)! TIA ===== After having found that certain versions of Informix (both SE and IDS) don't support the leap year date (Feb 29, 2000), I upgraded IDS to version 7.30.UC2 (SCO Openserver 5.05). I can now see that the leap year date works. However, to insert a date/time doesn't - using the following: dtcvfmtasc("022900 000109", "%m%d%y %H%M%S", &date_time_varaible) fails. My version of ESQL is 7.22.UC2. DBCENTURY = 'C'. Any ideas? =====
JLK62 wrote: > I'm reposting to make a correction to my original post (I accidentally > put the date in as '99' instead of '00' - which has been pointed out > by many a person on this list that 1999 is not a leap year, but 2000 > is)! > > TIA > ===== > After having found that certain versions of Informix (both SE and > IDS) don't support the leap year date (Feb 29, 2000), I upgraded IDS > to version 7.30.UC2 (SCO Openserver 5.05). I can now see that the > leap year date works. However, to insert a date/time doesn't - using > the following: > > dtcvfmtasc("022900 000109", "%m%d%y %H%M%S", &date_time_varaible) > > fails. My version of ESQL is 7.22.UC2. DBCENTURY = 'C'. Any ideas? Probably, your version is not safe from bug B65050 (or was it 69050?). Anyway, there's a bug in older versions such as (probably) 7.22, which means that you run into conversion errors on 2000-02-29 when you use an implicit (2-digit) year. You will probably need to upgrade to fix this. Note that the conversion in dtcvfmtasc() is done in the application by the ESQL/C library, so it is not sufficient to have a Y2K-safe server; you also need Y2K-safe client software. Check out the Y2K page at http://www.informix.com/informix/products/year2000.htm -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN #include <disclaimer.h>