Year 2000 [or design issues?]

Jonathan Leffler wrote: > > 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. Ah, the benefits of getting sign-off in writing! Then the customer can look like the fool to his boss when they have to spend a fortune in re-engineering. > > 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. > These are design problems/issues. Granted, sometimes these can't be avoided, but I've used some unique methods in 4gl to overcome space limitations. IMO, a crowded screen has major flaws (asthetics, usability, etc.) other than not having enough room for an extended date. > 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. But these issues are created because people allowed those forms to be created that way. Stop the problem at the source. I've never created a 2-digit year. Somebody has got to stand up for what's right. > > 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. > That is the most significant worth of the upgrade, as it would continue the implied century add-on when a 4-digit year wasn't entered. I bet that this could be easily handled without an upgrade (for those working on platforms that are no longer supported by Informix. Believe it or not, I've got software running on Unisys 5000 series boxes. The customers have no interest in upgrading because it works for them-- and cheaply now. [Of course, someday it will die]). Given the choice, though, I believe that the upgrade would be easier (cheaper) than writing a function and calling it with an AFTER FIELD in every date field. I guess what I'm saying is that I wouldn't have designed those screens that way in the first place, but if I did have the problem, I would first expand the date field. Then, if the customer wanted to upgrade the database to get DBCENTURY, that would be next. Either way, as you pointed out, the 4-digit year is needed on the screen to confirm to the user what they're getting. Tim