SimpleDateFormat.setLenient( ) behaves differently in jdk1.4 adn jdk1.6

Hi, we are using SimpleDateFormat class to parse date strings of format "MMdd". And we have the flag 'setLenient' set to false. We have the same application built on both JDK1.4 and JDK1.6.

On 29 Feb 2012, apps built in JDK1.6 failed to parse the "0229" date string with an exception
java.text.ParseException: Unparseable date: "0229".

However JDK1.4 built apps worked fine.
As an immediate fix to the issue we commented the code to set the flag 'setLenient(false)'. But we want to know
(i) which is the correct behavior - JDK1.4 OR JDK1.6?
(ii) If behavior of JDK1.6 is correct, how to Parse date strings like '0229' when 'setLenient' is set to false.

Please see a simple java code as attached whose output in:
Java1.4 is
Gonna Test setLenient() behavior
I am good..no issues

And in Java1.6 is
Gonna Test setLenient() behavior
Something gone wrong...Unparseable date: "0229"
java.text.ParseException: Unparseable date: "0229"
      at java.text.DateFormat.parse(DateFormat.java:337)
      at test.Test.main(Test.java:29)

 
Thanks a ton in advance.
damarasaAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ahoffmannCommented:
> ... date strings of format "MMdd" ...
this format is ambigiuos according the value 0229 'cause it misses the year

said this, I'd qualify the behaviour of any library correct as it's the library programmers decission to assume a specific year or to throw an error

so in my opinion both behaviours of jdk are correct for your value 0229, it's a programming error which results in a runtime exception
things are different if your value would be 0431, but that's not your question ;-)
0
damarasaAuthor Commented:
Thanks for the response ahoffmann.
So do you mean to say that 1.4 library developer is kind enough to ignore the year component and let the string "0229" pass through.
And 1.5 or 1.6 library developers were stringent and not entertaining any ambiguity.

Is the implementation not driven by the spec? Or the spec itself got changed?
Please clarify.
0
zzynxSr. Software engineerCommented:
The docs say this about setLenient():
With lenient parsing, the parser may use heuristics to interpret inputs that do not precisely match this object's format.
With strict parsing, inputs must match this object's format.

Without any notion of the year, in ~75% of the cases "0229" is an invalid date. So with setLenient() set to false this shouldn't pass.
So, imo the jdk1.4 approach was simply wrong. And that has been fixed later on.
0
Acronis Data Cloud 7.8 Enhances Cyber Protection

A closer look at five essential enhancements that benefit end-users and help MSPs take their cloud data protection business further.

ahoffmannCommented:
I'd insist that 0229 is the programmers fault, not that of the library, unless the library tells you how it handles MMdd, which it does not, quote:
   may use heuristics to interpret

all said: you get what you ask for: something random

being pedantic: ~75%  are not enough to qualify 0229 invalid as setLenient(false) can't guess the remaining 25%
and being more pedantic:
  assume following scenario:
  1. the library (jdk) uses the current year (whatever this means) if YY or similar is missing in the format
  2. the process starts 31. Dec. 2011 23:59:59
  3. the library call is executed 01. Jan. 2012 00:00:01
what should be the result, valid or invalid?

don't use ambigious code when you expect 101% truth
this discussion is simply useless, tell programmers to do it right
0
GRayLCommented:
Hear, hear ;-)
0
damarasaAuthor Commented:
ahoffmann, so what you are trying to convey is:
"do not parse date strings against MMdd format (with out year) - always check them against 'MMddYY' template".
Am I getting you right? Please clarify.
0
ahoffmannCommented:
yes
and I'd use full year YYYY, as YY may be ambiguous in rare cases according leap years too
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
zzynxSr. Software engineerCommented:
>> do not parse date strings against MMdd format (with out year)
Exactly. And that's what I - as a second opinion - tried to tell you too.

If they'd ask you: "Is Feb 29th a valid date?"
You'd replicate immediately: "That depends on the year"
Well, then why would you ask a library the same question without providing it that vital information?
0
ahoffmannCommented:
@zzynx
> Well, then why would you ask a library the same question without providing it that vital information?

I don't feel addressed, anyway: programmers (and much more managers) tend to ask a library and expect the truth, that's the virtual world
in a real world if *YOU* ask another human and if you get an incomplete, inaccurate resoponse, you verify your question and ask again, a dialog starts; that's what programmers need to learn from the real world ;-)
and unfortunately, there is no big difference between library programmers and application programmers, see quote: may use heuristics to interpret

just my 2 pence
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Programming Languages-Other

From novice to tech pro — start learning today.