damarasa
asked on
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
at test.Test.main(Test.java:2
Thanks a ton in advance.
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
at test.Test.main(Test.java:2
Thanks a ton in advance.
ASKER
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.
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.
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.
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.
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
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
Hear, hear ;-)
ASKER
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.
"do not parse date strings against MMdd format (with out year) - always check them against 'MMddYY' template".
Am I getting you right? Please clarify.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> 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?
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?
@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
> 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
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 ;-)