Re: Year 2000 problem/easy

In a previous article, timj_at_baa.uk.sun.com (Tim Jinkerson - Sun UK - Applications Engineer) says:

>In article 21BB_at_gate.net, nix <nix_at_gate.net> writes:
>> deng mei wrote:
>> >
>> > I have a easy solution for the so called "year 2000" problem:
>> > If YY < 75(e.g.,), then it is 20YY;
>> > If YY > 75, then it is 19YY.

 [snip]
>> Assume the current year is CCYY (i.e. for this year CC=19 and YY=96)
>>
>> if YY < 51 then year = (CC+1)YY
>> else year = CCYY
>>
>> This is a generic solution that will always work. Forever!
 [bzzzt]
>> ______________________
>> Robert C. nix_at_gate.net
>
>Bad news for my dad, look's like he hasn't been born yet!
>
>23/9/23 = 23/9/2023
>
>Fine for life assurance maturity dates, but won't work for life assurance
>acceptance criteria.
>
>Tim

It will work if you apply the proper format to your father's birthdate (along with the string format descriptor) before passing it to Oracle for processing.

Oracle will properly handle TO_DATE('23/09/23', 'DD/MM/YY') as well as TO_DATE('23/09/23', 'YY/MM/DD'). Note the "0" prefixed to the month: a necessity if you're going to obviate ambiguity, not only to an SQL parser, but to humans as well. And to avoid further date-based ambiguities  in the coming years, you could simply use a YYYY year format in all your DATE-related code. That way, things which are stored in the 20th century will not be mistaken for 21st-century entries.

As numerous religious leaders have harangued us over the years: "Convert now. Avoid the rush."

Karla Johnson

-- 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Karla Johnson                       |      Internet: karjohn_at_kincyb.com
S/W Engr., Informax Data Systems    |                  or ab803_at_lafn.org
Los Angeles, California             |   Standard disclaimers, ad nauseam