when trying to validate the booking date (format yyyy/MM/dd) I use the following code snippet:
But actually this is not what I expected, because this returns a valid date as well for "2010/13/00" as an example.
So is there any method which can tell me if a given date is existent or not (considering leap years etc.)?
From the javadoc:
By default, parsing is lenient: If the input is not in the form used by this object's format method but can still be parsed as a date, then the parse succeeds. Clients may insist on strict adherence to the format by calling setLenient(false).
So adding following code before date parsing will solve your problem:
Following examples are all valid:
"10/1/01", "2010/1/1", "10/1/1" instead of what I would expect, namely : "2010/01/01"
What I do now additionally to avoid this is to check the length of the date and compare it with the length of the pattern.
But anyway is there another trick doing this automatically?
I didn't do any date validations and stored the date just as a String, because you can only update the customer id, all other values are immutable in this assignment, so why bother to try parsing this date. You could use a combination of a Pattern (\d\d\d\d/\d\d/\d\d) and the SimpleDateFormat.
Carlos Morillo wrote:Is there a need to do any Date format validation in the assignment?
The only data field to be modified and updated is the customer id.
I am assuming the Date data fields are just Strings and they are correct and valid as they are.
Exactly my point in my previous post
I am just waking up and took a very quick glance to the thread ...
My bad sorry I missed that.
What i did was take the date from the selected reservation, convert to time that i could do calendar arithmetic on it to make sure the date was <= 48 hrs. if it wasn't then
reject the attempt to book the reservation.
I am not implementing the 48 hours rule also like Roel.
All the hotel data records in my assignment's original database file that I got in May 2009 have
dates with a year 2003-2005, so in my view it doesn't make any sense if you use the present time
April 27th 2010 using the 48 hours rule to book a hotel room that is available in the past.
The only way it would make sense is perhaps if you have a way to generate a database file
with dates in the future from today and this is not the case since it is a MUST requirement to use
the original file provided from Sun, and since this is not a MUST requirement and for the sake of
simplicity I am not implementing it.