Re: problems with RRRR format

A couple of small points to clarify: the variable for NLS_DATE_FORMAT should always be defined within the valid choices according to the NLS_LANGUAGE you've selected. NLS values may be set at database-creation time; at instance-mount time (using INIT.ORA); or for the duration of the current session.

[Quoted] For the "AMERICAN" language settings, with apologies to Tommy, the remediated year value is valid in both two-byte and four-byte templates. Remember that in Oracle RDBMS, the DATE datatype is actually a "masked" varchar type -- the two vs. four display is simply a view of the underlying data.

How this sliding-window date format "interprets" the two-byte display is dependent upon the SYSDATE value. The "implied" century columns are interpreted one way for system dates in this century, but that shifts once the system date rolls over.

Of course, RTFM for specifics.<grin>

Food for thought -- why isn't anyone talking about the issue that "compliant" systems cannot fix badly written source code?

JMTC,
Dave

Tommy Wareing wrote:
>
> On Tue, 10 Nov 1998 02:20:54 GMT, ravipadma_at_aol.com wrote:
>
> >We are planning to use RRRR format at the form level for Y2K compliance. Did
> >any of you experience problems with this format. Thanks a lot in advance.
> >Ravi.
>
> a) We've never used it, but I think it's RR, not RRRR.
> b) The reason we've never used it is that we have to deal with dates
> before 1950. RR turns 50-99 into 1950-1999, and 00-49 into 2000-2049.
>
> It's not truly compliant (IMO) unless you can enter (for example) both
> 1949 and 2049. This means 4 digit year fields.
>
> --
> Tommy Wareing
> MIS Group
> Learning Resources
> Oxford Brookes University
> 01865 483389
Received on Thu Nov 19 1998 - 00:00:00 CET