RE: year 2000 question

---------- From: oss96@batelco.com.bh[SMTP:oss96@batelco.com.bh] Sent: Monday, February 02, 1998 1:39 PM To: informix-list@iiug.org Subject: year 2000 question Dear all, We are planning to implement the "01/01/1980" solution for our 4GL application .Our screens has 2 digits for year in date field, we are not going to change this but dates between year 1980 and 1999 will be interpreted as 1980 and 1999 . Dates from 1900 and 1970 will be interpreted as 2000 year so 1905 will be interpreted as 2005 and so on. Does anybody choose this senario ? Any problems encountered? I've not heard of anybody trying this, and I wouldn't recommend it at all. Here's why: 1. Your description isn't clear about dates with the year part entered as 71..79. It could be that you are planning to disallow such dates, or they could be interpreted as 1971..79 or as 2071..79. I guess that's a typing problem in your message, but that doesn't alter the fact that you appear to be missing a range of numbers. 2. It appears that you are proposing to store dates such as 1900-01-01 and yet have the application treat this as if it was 2000-01-01. There are several problems with this. The biggest is that the whole system will be confused because it will, for example, sort 1900-01-01 before 1999-12-31, but your semantics require the reverse. All I4GL date comparisons will have to be revamped to use a subroutine you write instead of the built-in comparisons. And making sure that everywhere is changed appropriately will be hell. 3. There was no 1900-02-29 but there is a 2000-02-29, so there is at least one date which is not representable using this technique. 4. Even the DBCENTURY-aware versions of I4GL (4.20, 7.20) will not help you implement this. The closest approximation to your desired behaviour is probably DBCENTURY=C (closest), but that has a 50-year sliding window on the dates, not the fixed interpretation you seek. It would be much more sensible to redesign your forms so that they display 4-digits for the year. Much, much, much more sensible. If you do that, you can store dates in native format (there never has been a storage problem for dates in the 21st Century), and the actual values will be displayed correctly, and the sorting and comparison logic does notneed to be changed, and will work with DATETIME too, etc. As I said earlier, I don't think your proposal is sensible. The sensible solution is to display 4 digits for the year. Yours spouting forth yet again on Y2K and I4GL, Jonathan Leffler (jleffler@visa.com) #include <bother.ms-exchange.h> PS: To see my previous rants on this subject, go to DejaNews and look in c.d.i for articles by me (or johnl@informix.com - my previous email address) with Y2K or 2000 or DBCENTURY in the subject. You'll find 'em.