Re: Year 2000...

}Date: Thu, 06 Feb 1997 12:50:58 -0700 }From: "Timothy M. Hood" <timhood@sisna.com> }X-Informix-List-Id: <list.13024> } }Jonathan Leffler wrote: }}X-Informix-List-Id: <list.13024> }}[...Lots of stuff, mainly pointing out...] }} }} ************************************************************* }} *** PLEASE, PLEASE, PLEASE, PLEASE *** }} *** MAKE SURE YOU ALWAYS DISPLAY ALL 4 DIGITS OF THE YEAR *** }} ************************************************************* }} }} For your own sanity, please get all your code/forms which do not display }} 4-digit years and fix them so that they do. }I'm not clear why anyone would be having this problem! The way I see it, }expecting that an application written as late as the '80's wouldn't be }needed for the year 2000+ would be extremely short-sighted. As such, I }wouldn't let it pass system test or user acceptance, and as a developer }or project leader I wouldn't stand for it. (Removing soap-box: ) There are two reasons. 1. Some people try to cram as many fields as possible onto a single form, and if you have lots of date fields, saving two characters per field lets you get more stuff onto the screen. 2. Some people absolutely refuse to let the application show more than two digits for the date, despite strenuous representations that this is silly. I encountered this problem several times. Since they were the customer and were paying for the work I did, then ultimately, I had to acquiesce, making sure it was clearly understood that it was being done over my metaphorical dead body. }Allowing the scape-goat that "it's not my code", what's the big deal }about modifying a screen form to extend date fields by two character }spaces? MAKE IT FIT! Having a two-digit year is akin to having only 8 }characters of a 10-character primary key! I would venture to say that }95% or more of 4gl screens could be easily modified. Agreed, more or less. However, with applications in category 1, I've seen forms with 20 lines of form fields all separated by '|' symbols, and every numeric field already at minimum size. The other lines are needed for the menu, comments and error messages, of course. Those programs are excruciating to use unless you are extremely familiar with them, of course. Finding the right field in the mess is next to impossible, not least because you have to tab through the fields till the correct comment line appears -- there are no cues on the screen. The other part of the big deal is simply that there are lots of forms to be modified. The original question mentioned a fairly small system, only about 150 programs to be fixed. That shouldn't take more than a couple of weeks sustained work for a single person, unless each program has a very large number of screens. }And considering the wonderful fore-sightedness of Informix (at least I }hope it wasn't just accidental) to store the date as an integer, the }value in the database would automatically be correct. Hence, just }recompile some screens and you're set. Yes, though the data entry clerks who are used to typing 97 to get 1997 will find it difficult to remember to type 2000 to get 2000 if the version of I4GL is not upgraded. This is why the DBCENTURY upgrade is needed (even though it is not available yet). }I've not messed with DBCENTURY, largely because of the vast expanse of }engines in the installed base that don't support it. But I wouldn't be }too likely to use it because the support issues associated with the }dates working for different users. There are two changes that come with DBCENTURY. First, if the environment variable is set, then you can tune the way 2-digit years are treated. Secondly, and probably more importantly, if DBCENTURY is unset and the current year is in the 1900s, then 1900 is added to the 2-digit year, but if the current year is in the 2000s, then 2000 is added to the 2-digit year. This second feature is arguably the more important. }Plus, not all dates need to be treated the same way. Birthdays would be }more likely 19xx, dates in the future more likely 20xx, and dates in the }past could be either. Absolutely correct. }The best solution is to ALWAYS use a 4 digit year and let the user type }exactly what they want, IMO. No 4gl or engine upgrades would be needed. The second feature of DBCENTURY support is valuable and an upgrade is therefore beneficial. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> }From ilist@rmy.emory.edu Thu Feb 6 13:31 PST 1997 }To: informix-list@rmy.emory.edu }Date: Thu, 06 Feb 1997 12:50:58 -0700 }From: "Timothy M. Hood" <timhood@sisna.com> }Mime-Version: 1.0 }Subject: Year 2000... }Content-Transfer-Encoding: 7bit } }Jonathan Leffler wrote: }} }} Comment 1 }} This means one of two things: }} * You aren't looking at the dates when you type them. }} * Your programs do not show all 4 digits of the year. }} I regard the second option as the more likely. The only sensible fix is to }} change your programs to display all 4 digits of the year. This has been }} true since before I4GL was introduced to the market, and will remain true }} into the indefinite future. }} } } }} Comment 1 reiterated }} Even if you upgrade to a version of I4GL that supports DBCENTURY, }} unless you display all 4 digits of the year on the screen, you won't be }} able to tell whether it is working correctly for you. Unless you }} revise the code to display the full 4-digit year, your code will be }} unreliable. }} }} If your application is designed to run with DBCENTURY unset, then if }} you type 23/01/10 (with DBDATE set to dmy4/) after 31st Dec 1999, then }} the value will be translated as 23rd Jan 2010. However, if someone }} accidentally has DBCENTURY set to P, then the value will be translated }} as 23rd Jan 1910 until after 2010, but you won't be able to see that }} something has gone wrong unless all 4 digits of the year are displayed. }} }} ************************************************************* }} *** PLEASE, PLEASE, PLEASE, PLEASE *** }} *** MAKE SURE YOU ALWAYS DISPLAY ALL 4 DIGITS OF THE YEAR *** }} ************************************************************* }} }} For your own sanity, please get all your code/forms which do not display }} 4-digit years and fix them so that they do. }} }} When you get the necessary upgrade to I4GL, then you will be able to have }} DBCENTURY set, and you will be able to enter 2 digits for the year, and }} I4GL will display the 4 digit year, and you and your users will be able to }} see that I4GL did what you wanted it to do. }} }} Yours, }} Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> }} }} PS: I've been saying this to clients since 1986, long before I joined }} Informix. I've been saying this in c.d.i since 1991. It is still, I }} regret to say, necessary to reiterate it -- use 4 digits when you display }} dates! } }I'm not clear why anyone would be having this problem! The way