Date format RR limitations.

Why did Oracle introduce the RR format. It's funny how assumptions can make you fall flat on your face. I assumed I new how the RR format conversion worked until I RTFM.

Assuming my understanding of the RR conversion is correct, was it introduced by Oracle just to comply with Y2K. I don't see why it needed to. There is some discussion about handling two digit years in the Y2K white paper, but surley the RR format is against the princple of Y2K compliance because it only moves the problem on 50 years.

I know there is an argument that we should all enter four digit year codes but why? My user says to me, 'I have a screen with 10 dates. As the dates I enter are only ever within 5 years why oh why can't it default sensible. Computers were designed to make life easier:-)'. I say, 'No problem the RR format (or even better RRRR) is just the ticket.' However now I've read the manual I beleive RR should not to be used because it will introduce the same problem in the year 2050. Even though I won't be around by then my principles say don't use it.

This is how I assumed the RR format worked.

RR should defualt the century to the date that's nearst the current date.. e.g.. if 02 is entered 2002 is nearer not 1902 or 1802. If the current date is 2050 and 49 is entered then 2049 is nearest, not 2149 or 1949.

The other main type of date where this would not work is DOB (date of birth).

A new format character could be introduced to cover this , say UU (or what ever letter is available), which would always defaults to the previous century if the YY portion was greater than the current date.

These changes along with the 4 digit variant would surley cover most enventuallities and make my customer and me happy. I could write a clever function which simulates the format function to do what I wish but I don't really want to do this.

Please say I've read the manual incorreclty or there is something wrong with my logic. I would gladley suffer a red face to be corrected. Received on Tue Mar 02 1999 - 05:03:50 CST