2 Digit Year Reveals Inconsistent Results

Question

As I have read what I can about implicit versus explicit dates, I have come across something I find a bit odd.  I've tried to simplify it here in this anonymous block.
declare
bad_year varchar2(30);
good_year varchar2(30);
neutral_year varchar2(30);
testdate date;
neutraldate date;
begin
testdate := to_date('01-JAN-50', 'DD-MON-YY');
--test one
bad_year := to_char(testdate, 'DD-MON-YYYY');
dbms_output.put_line(bad_year);
--test two
neutral_year := to_char(testdate, 'DD-MON-YY');
neutraldate := to_date(neutral_year);
good_year := to_char(neutraldate, 'DD-MON-YYYY');
dbms_output.put_line(good_year);
end;
The results:
01-JAN-2050
01-JAN-1950
I would think that unless you are altering your session between tests and changing the NLS_DATE_FORMAT, that the results would at least be consistent.
This has truly got me stumped.
Anyone out there understand this?
thank you,
Kristi

Answer 1

kbarry wrote:
For the record, I never would have blindly started coding implicit date formats without looking into it first.  I believe it is just that I did not see all of the documentation and what I did see, I apparently did not understand as thoroughly as I thought I did.  And I guess I tend to assume that if a language offers constructs with a set of rules behind them, that it is okay to use those constructs so long as you follow the rules.  But more and more, I hear of things that should never be used, such as global variables, and now implicit date formats.  Why offer such language constructs if they should never be used?  I suppose if it was that straight-forward, there would be no fodder for the forums.
Nevertheless, I truly appreciate the prompt answers.
Some constructs seemed like a good idea at the time, but practice has shown them to be not such a good idea after all.  Like a GOTO statement
Some constructs have legitimate uses, but are more often abused and used in ways the original designers never intended.
Some constructs (such as the RR date format) are, as I mentioned in an earlier post, emergency solutions to intractable problems - with the understanding by the original designers that the feature should only be used until the underlying problem is fixed.
Those of us who were actually engaged in applications programming in the late 90's are particularly sensitive about dates.  We busted our butts for at least two years insuring that Y2k passed without a problem.  And exactly to the degree we were successful, people thought then, and still believe, the whole thing was a hoax.  I had to explain it again to an 'unbeliever' just a couple of weeks ago.  Problem is, some of the fixes relied on things like RR date formats, and 'moving windows', which got us through, but just kicked the can down the road.  At which point, once again, today's problem - like reformatting a sales report for a VP - became more important than the one we knew was down the road.  And with the passage of time, the one down the road was completely forgotten. 
And while I'm ranting on the subject, let me point out for the benefit of those who weren't there that in spite of everything they might have heard, Y2k was not a problem with COBOL.  It was a problem with the design of the data.  COBOL was quite capable of handling 4-digit years, if only the apps designers had allowed for 4 digits in their data.  There are valid, historical reasons why the didn't, but it was not due to a limitation in COBOL or any other language.  The only reason COBOL got so much attention was that it was the dominant language at the time.  <rant off>