Blogs

During a recent class I taught on ICEfaces, one of my students asked me why the calendar was often one day off from what got posted back to the model managed-bean setter.

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.