Re: use of DBCENTURY, How then?

On Wed, 15 Jul 1998, Chuanlarp Satchavarodom wrote: > I have seen discussions about the usefulness of this variable. > But please someone tells me how to set it up in the log in profile. Add the following to /etc/profile or $HOME/.profile: DBCENTURY=C export DBCENTURY Add the following to $HOME/.cshrc (I don't think there's an equivalent file in /etc): setenv DBCENTURY C I think that C (closest) is the most helpful value for many purposes, but not if you are dealing with birthdates. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix -- see http://www.perl.com/CPAN > Jonathan Leffler <jleffler@informix.com> wrote: > >On Tue, 14 Jul 1998, Infodata wrote: > >> I would appreciate some insight into the use of DBCENTURY variable. > >> Do both the tool and the server require to support DBCENTURY, to use > >> its features, or is it sufficient for the server to only have this > >> capability? > > > >It depends on how much you like nasty surprises. > > > >* If you don't mind them, then you can use a mixed-capability > > combination. > >* If you don't like them, then you should use a matched set of tools and > > engines. They should either both be aware of DBCENTURY or, possibly, > > both unware of it. It is recommended that you upgrade to > > DBCENTURY-aware software. If you don't, make sure you always display > > all 4 digits of the year in every date that is displayed. If you > > don't (won't) do that, expect problems. > > > >The problems occur when a date is translated from a string into a DATE > >value and the string only has 2-digits for the year. If your > >application doesn't handle DBCENTURY, it will always add 1900 when it > >does the conversion; if the database handles DBCENTURY, it might add > >1800, 1900, 2000 or even 2100, depending on DBCENTURY and the current > >date. Or the reverse could be true if the database is not aware of > >DBCENTURY but the application is. Consequently, you might get different > >answers when the engine does the conversion and when the tool does the > >conversion. > > > >If the tool is I4GL, most of the date conversions will be done in the > >front-end code and it would be silly not to upgrade to a DBCENTURY-aware > >version of the software, unless you are sure that all your dates are > >displayed with 4 digits for the year and your users are used to typing > >all 4 digits when they enter the year -- and that is improbable! They > >will probably just type 2 digits for the year and it automatically gets > >converted from 98 to 1998; the snag is, when they type 00, it will be > >automatically converted to 1900 once the century rolls over. The > >documentation says that 1900 is added, and it means 1900 is added. > > >> What are the values that can be assigned to this environment variable? > > > >According to TFM: C, P, F, R > > > >> I understand that it can be used to change the default century to the > >> century closest, before or after the current date. But what are the > >> respective settings for these? > > > >C, P, F