I am using the richfaces calender and set the pattern datePattern="dd MMM, yyyy". In the client side it is showing as I desired. Suppose 13 oct, 1976. But when ever I am saving it in database its saving like this Wed Oct 13 00:00:00 IST 1976. What should I do to save it in my desired form.
The datePattern in the rich:calendar control converts from a Date object to String representation and String to Date. You're saving the raw date in your database, and when you see it as Wed Oct 13 00:00:00 IST 1976, that's because of the formatting pattern of whatever tool you're using to view the database. You can probably update that to whatever you prefer, but how you do it depends on the tool you're using. For example, in Oracle SQL Developer, you'd go into Tools -> Preferences, select Database, NLS Parameters, and change the Date Format field.
If I understand correctly question the answer is the selected value in richfaces calendar is stored in bound bean's property.
In your demo you store selected date into property staffDOB of RegistrationBean by :
Of course staffDOB must be of type Date.
But I recommend to use converter to format date into needed format before it is stored in staffDOB property. This way staffDOB property will be assigned to Date you format in converter. You can use my code of SimpleDateFormat to format date in converter.
Look at example of simple converter at http://www.mkyong.com/jsf2/custom-converter-in-jsf-2-0/
Yes, that's right. The calendar component converts the string date into a Date object, which is set to a property in your managed bean. It could be converted back to a string before being stored in the database, but of course this would mean altering your database schema to accept a string in that field. it also would make date operations like sorting or selecting by a date range much harder. I don't recommend doing this.
As I said already, the date is not being stored incorrectly in your database. Your database tool is just using a different format string when it displays dates back to you. You can change that if you want. It has no affect on your application at all.
Incidentally, databases can be quite treacherous when it comes to date/time data. The granularity of the various Java objects and the granularity of the database objects often have no direct correspondence. For example, in Oracle, a date may have a granularity in seconds, but the closest Java object that contain such values has millisecond granulatity. If you manipulate those objects and then write them to the database, some precision will be silently lost. It doesn't help that there's no real standard for the precisions of the various date/time objects between the different database vendors.
I've found that the best way to consider dates in such cases is to treat them the same way that you would treat floating-point numbers. Among other things, that means don't use them as database keys for "compare-equal" operations.
Also, when storing date and time data into a database from a webapp, I recommend normalizing the value (if needed) to UTC timezone unless you are totally certain that all users will operate from a single timezone.
Customer surveys are for companies who didn't pay proper attention to begin with.