Hi all, I would like to check the validity of a string obtained from my GUI . It is in the format ddMM and when i used the following program, I coudn't get the required result. Please note that I have caught the Exceptions, but is not mentioned below.
I could read the reason for the behaviour from API doc and could get some information from archive. I could solve the problem by adding the current year with ddMM.
I would like to know whether there is a any other simple method to solve this problme.
> I would like to know whether there is a any other simple method to solve this problme.
what is the problem?
you've specified ddMM, so it will default to 1970, which is not a leap year i.e. there's no 29 Feb 1970, so will error with setLenient(false)
Joined: Nov 27, 2006
Thanks for the replies.
My aim is to check the validity of the date for the present year, and for the coming years. What I meant is , if the date is a valid date for the present and next years, it should not throw exception and otherwise it should throw an exception.
When I run the code suggested by Ajay Singh, I got a result as "date is Sun Mar 01 00:00:00 GMT+05:30 1970". I want to get ParseException instead of this (This is the problem which I mentioned).
Also is there a method to check the validity of the date with respect to current year and next year by using java classes rather than checking the validity with respect to 1970.
Joined: Jun 09, 2003
this might be one way
tests for current year. for testing next year, just add 1 year to the calendar and re-test
Joined: Nov 27, 2006
Thanks for the immediate reply
I was unaware of the use of Calender class and the reply really helped a lot.
Thanks once again specially to Michael Dunn, Ajay Singh and JavaRanch
A friend of mine once hand coded a COBOL table with 1231 entries in it and used mmdd as an index. In Java it would look something like ...
There was a special check for 0229 but that's it. The program did about 50 complex date functions with an astonishingly short execution path, something like 400 assembler instructions on the average call.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 29, 2003
Boy, won't anything get a burst of outrage on this forum?
I agree - I enjoyed COBOL and make a point of not saying bad things about it. But I actually liked that table of 1231 entries. All but 366 were empty. I still have the source if anybody needs it. You can guess how he determines if it's a leap year ... it's not with modulo 4. [ January 25, 2007: Message edited by: Stan James ]