Re: LEAP YEAR PROBLEM

While the "fix" is easy, I'm betting the output will no longer be what your users really want. For instance, on March 1st, 1996, they probably want one_year to be 03/01/1995, three_year to be 03/01/1993, and five_year to be 03/01/1991. If informix does it's computations correctly, it should know that 1996 and 1992 have 366 days in them, so your dates will be incremented forward accordingly. If your users can decide what they really want when they want 1, 3, or 5 years ago on Feb 29 (they'll have to settle for 2 consecutive days of Feb 28th output or 2 consecutive days of Mar 1st output), then you could horse around with separating out the date into month, day, and year, incrementing/decrementing the appropriate parts, then reassemble these into the date format for your query. ______________________________ Reply Separator _________________________________ Subject: LEAP YEAR PROBLEM Author: tallred@mercury.interpath.com (Tom P Allred -- Systems Integration) at smtpgate Date: 2/29/96 3:20 PM We have run into either a bug or some bad programming. A program we've used for some time suddenly started giving datetime conversion errors (1267) today, February 29. Here is the offending code segment: function date_test() define one_year date, three_year date, five_year date let one_year = current - 1 units year let three_year = current - 3 units year let five_year = current - 5 units year ( rest of function ) Each of the let statements generated the -1267 error. I'm guessing it is because there is no February 29th in any of the earlier years. Fixing the problem was pretty easy. I did the following: let one_year = today - 365 let three_year = today - (365 * 3) let five_year = today - (365 * 5) Has anyone else hit this today? Is it a bug, or just bad programming? I didn't write it, BTW, so criticism won't bother me. Thanks, Tom Allred tom@systems.rwbost.com