Re: 4GL Question (4-digit years *MUST* be displayed)

On Thu, 11 Feb 1999, Dennis Pimple wrote: > henriquelima@uol.com.br wrote in message > <79t9t2$kl1$1@nnrp1.dejanews.com>... > >try using "picture dd/mm/yyyy" on the .per files. > > > (hopefully) Clarifying the above. > > If you're refering to a date data type, either by referring to a database > column of type date or a formonly variable of type date, the syntax is > format = "mm/dd/yyyy" or whatever. This won't require actual 4-digit year > input, but does show a four-digit year as the user exits the field. Thus a > user can input 1/1/00, and as the cursor leaves the field it will change to > 01/01/1900, or 01/01/2000, depending on the $DBCENTURY setting. There are two attributes: FORMAT and PICTURE. See the code below. The notation used by Henrique combines elements of both. Experimenting with the sample code below, you have to type 2 digits for the day and month components, but you can type 1 to 4 digits for the year component, and you can 'tab' out of the field or hit accept, so (as I stated a week or so ago) you can't actually enforce 4-digit year during data entry. Well, you *can*, but only if you insist on the year being entered first, as in a DATETIME field, by using the attributes PICTURE = "####-##-##", FORMAT = "yyyy-mm-dd". This is, of course ISO 8601 compliant. The sample code assumes DBDATE="DMY4/"; I haven't been completely Americanized yet. And this is the biggest problem with using a FORMAT clause; you also force a particular date format and it is difficult to allow for cultural variations. > Is this y2k compliant? Jonathan and I say yes, but other rules may be > more specific. Forcing people to enter 4 digits for the year is not particularly good UI engineering, so I wouldn't (and don't) get hung up on it. But equally, not displaying all 4 digits for the converted years is *bad* UI engineering. When 7.3 I4GL and 3.0 D4GL are released, they will have a new form attribute, CENTURY = "[FPRC]". This will allow you to specify which DBCENTURY-style conversion attribute applies to this single field, so you will be able to have a form which stipulates that certain fields (like date of birth) are always historic, but other fields (like planned retirement date, or maturity date for a mortgage or pension) are always futuristic (is that the right word for this context?). We believe that this will deal with most of the remaining issues, as long you display all 4 digits for the year. Take a look at the code in date2.per (below). It does away with the picture attribute, but only displays 2-digits for the year. When I was using it, it was called date.per, and I used the same test program, date.4gl. You can type '11112000' into the field, but the value converted by the program is 11th November 1900. There are reasons for this; the string is initially converted to 11th November 2000, but then the value is display as "11/11/00", and then the displayed string is reconverted, and (since I had no value set for DBCENTURY), the date was reinterpreted as 1900, not 2000. And note that if I didn't show the 4-digit version of the year, the user would not be aware of this mismatch, and whether they were aware of it or not, there is nothing they could do to fix the problem until the form displays all four digits for the year. It is also, IMNSHO, worth putting CHECK constraints on all DATE and DATETIME columns in the database. You can almost invariably do so. Date of Birth columns should have a constraint: CHECK(dob < TODAY). More controversial are future dates: CHECK(ship_date >= TODAY). This becomes invalid with the passage of time, and also doesn't allow for the mad rush at the end of quarter when you ship stuff but don't do your book-keeping until the next day, or something similar. You can probably do CHECK(ship_date >= TODAY - 30) which means you have to record shipments within a month of shipping them. The date2.per form below shows why you *MUST* show all 4 digits for the year, as I've been saying in this news group for several years now. > You could actually force 4-digit year input by changing the data type > of the field to char, and use picture = "##/##/####", but now you have > a lot of parsing and checking to make sure that a valid day, month, > and year has been input. A lot more 4GL code changes required there. Strong recommendation: do *NOT* use CHAR fields to enter DATE values. > >In article <36bf3377.8641702@client.se.news.psi.net>, > > boost_me@yahoo.com (Bob) wrote: > >> I am working on a Year 2000 problem. I have many .per and many .4gl > >> to work with. I am trying not to have to modify the 4gls if possible. > >> > >> The question is how can I force the user to enter a 4 digit year in a > >> type date field, while also giving them the ability to enter or change > >> the value to a NULL? All these forms are being accessed from 4gls and > >> are not ISQL Perform screens run from the Perform menu. > >> > >> Database 7.2x -- 4GL 6.0 Yours, Jonathan Leffler (jleffler@informix.com) #include <wish/I/was/skiing.h> Guardian of DBD::Informix v0.60 (v0.61_02) -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn -- date.4gl -- MAIN DEFINE d DATE OPEN FORM f_date FROM "date" DISPLAY FORM f_date WHILE TRUE INPUT d FROM formonly.* DISPLAY "Previous entered value: ", d USING "dd mmm yyyy" AT 6, 1 END WHILE END MAIN -- date.per -- DATABASE FORMONLY SCREEN { DATE field [f000 ] } END ATTRIBUTES f000 = FORMONLY.datefield TYPE DATE NOT NULL, FORMAT = "dd/mm/yyyy", PICTURE = "##/##/####"; END -- date2.per -- DATABASE FORMONLY SCREEN { DATE field [f000 ] } END ATTRIBUTES f000 = FORMONLY.datefield TYPE DATE NOT NULL, FORMAT = "dd/mm/yy"; END