Re: Informix 4GL and year 2000 problems/ramblings

On 8 Dec 96 at 0:52, Joel Schumacher wrote: > 1) First of all, I've heard various things about DBCENTURY. I've heard > it only applies to the engine and not the tools. I'm not concerned > with the engine, I'm concerned with dates input from 4GL screens. Now I'm confused. How is DBCENTURY going to do anything if it only gets used by the engine? My current understanding of DBCENTURY is that you can set it to be a specific century or the century closest to the system date and it works for all tools. Hm, maybe not! :-) > I've heard DBCENTURY has no effect to any of the 4GL versions. > Is this correct? It might be true, although I'm sure they'll fix that soon enough... > First of all, users are still going to type MM/DD/YY dates and 4GL > still defaults them to the 1900's, (even if I set my clock ahead). > And if the user isn't looking, they've just entered a 1900 date when > they meant to enter a 2000 date. This is exactly what DBCENTURY is supposed to solve. > Users will still key DD/MM/YY and they're going to expect the > computer to know what they meant. And that's something we as > developers should be able to do for them. If it's an unusual date, > (ie. an 1899 birthdate) then they can key all 4 digits of the year. Yes. > 4GL is going to have to be able to handle 2 digit years better than > turning DD/MM/YY into than DD/MM/19YY. If it doesn't already (I haven't checked, to be honest), it will do soon. I couldn't believe even Informix would be that dumb. Or maybe they're hoping everyone will migrate to NewEra before 2000... :-) > Also thought about redoing the date fields to formonly CHARs and > writing my own date conversion routines. Really don't want to have > to do this, but right now it may be the best solution to provide a > solution to a problem Informix wont address. I don't think they won't, I'm sure they have. > 3) As I've stated in an earlier post, even if DBCENTURY is available to > 4GL, it's unacceptable because it's an environmental variable. In > other words a "global constant". Such a thing is not suitable for all > all applications. See above - it can be set to the century closest to the system date. > One application may have a variety of dates, like employee birthdate > (always in the past). The same screen may have retirement date or > review date (future). Other fields may need the "closest" logic. Ha - now this is tricky. My feeling (as another developer who has many, er, users) is that there isn't really much you can do about this. Using the logic below, if I was born in '45 and retired in '99, you'd have me retiring in 2099. And I'm buggered if I'm waiting that long! :-) > If Informix will provide something to set the default on demand, > great! Something like: > > BEFORE FIELD birth_date > CALL set_dbcentury("P") # past (closest previous year) > > BEFORE FIELD retirement_date > CALL set_dbcentury("F") # future (closest future year) > > Yes, we'll have 4-digit year screen fields, but as in issue #2 > above, the problem isn't entering and displaying 4-digit years, > it's allowing the user to enter MM/DD/YY (as I believe they will > prefer to do) and guessing correctly what they meant. You'll be wanting to try Microsoft Telepathy as your development tool, then! :-) -- Ciao, Billy I'd be in favour of apathy, but I just couldn't be bothered...