Friday, 30 July 2010
Working with JSF's f:convertDateTime and java.util.Date
« The ICEfaces 2.0 Component Story | Main | ICEfaces Enterprise Edition 2.0 Update »During a recent class I taught on ICEfaces, one of my students asked me why the
For example:
// Facelets XHTML Markup:
<ice:selectInputDate value="#{modelManagedBean.dateOfBirth}">
<f:convertDateTime pattern="MM/dd/yyyy" />
</ice:selectInputDate>
// Java Code
import java.util.Date;
public class ModelManagedBean {
private Date dateOfBirth;
public Date getDateOfBirth() {
return dateOfBirth;
}
public Date setDateOfBirth( Date dateOfBirth) {
SimpleDateFormat dateFormat = new SimpleDateFormat("MM/dd/yyyy hh:mm z" );
// The value printed here during postback was often wrong by 1 day
System.out.println("dateOfBirth=" + dateFormat.format(dateOfBirth));
this.dateOfBirth = dateOfBirth;
}
}
Basically, the JSF DateTimeConverter Javadoc states that if the timeZone attribute is not specified, then the default is GMT. But when you create an instance of java.text.SimpleDateFormat, the default TimeZone is equal to TimeZone.getDefault() which (for me) was EST. So the solution I explained to my students was to make sure we were comparing apples-to-apples the whole way through, by using GMT for the SimpleDateFormat printing, like this:
dateFormat.setTimeZone(TimeZone.getTimeZone("GMT" ));
And of course, I think it's the recommended practice to run your application server JVM in GMT. That would eliminate the problem entirely. But when you're using Eclipse and Tomcat for development, that's typically not the case.
Posted by at 1:01 PM in Entries by Neil Griffin
[Trackback URL for this entry]