DateUtil.setDefaultDisplayTimezone bug?

[dzarras]

I'm experimenting with different Date formats in ListGrid cells.

I have a Date instance that should read "Sep 8, 2011 22:00". I want to control the TimeZone setting of my GWT app to be Pacific Standard Time.

This code:

    DateUtil.setDefaultDisplayTimezone("-08:00");
    DateUtil.setAdjustForDST(true);
    ...
    globalMaxTimeField.setType(ListGridFieldType.DATE);
    globalMaxTimeField.setDateFormatter(DateDisplayFormat.TOUSSHORTDATETIME);

renders the above Date as "09/09/2011 22:00"

If instead I don't set the field's CellType or DateFormatter, but register a custom CellFormatter:

final TimeZoneConstants timeZoneConstants = GWT.create(TimeZoneConstants.class);
final DateTimeFormat dtf = DateTimeFormat.getFormat("MMM d, yyyy : HH");
final com.google.gwt.i18n.client.TimeZone usPacific = com.google.gwt.i18n.client.TimeZone.createTimeZone(TimeZoneInfo.buildTimeZoneData(timeZoneConstants.americaLosAngeles()));

CellFormatter dateTimeFormatter = new CellFormatter()
{
     public String format(Object o, ListGridRecord listGridRecord, int i, int i1)
     {
          Date maxDate = listGridRecord.getAttributeAsDate("globalMaxTime");

          String retValue = maxDate != null ? dtf.format(maxDate, usPacific) : null;

          return retValue;
      }
};
globalMaxTimeField.setCellFormatter(dateTimeFormatter);

It renders CORRECTLY as "Sep 8, 2011: 22". Note the difference in the day of the month: 8 vs. 9.

What's really strange with this case is that I've compared many other datetime values in my table with both formatting implementations, and only this Date value suffers from the problem. Note that the ONLY changes I'm making in my code in both cases are shown above.

Isomorphic: Any thoughts?


Is there a generalized discussion document of TimeZone support in the SmartGWT documentation somewhere? I found that nasty TimeZone construction code this morning here:

http://code.google.com/p/google-web-...st.java?r=3655

Thanks.

[Isomorphic]

There's a general discussion of date, time, datetime and timezone handling here.

Not sure what's special about your one bad date. That's not the DST cutover date obviously. There could be something about how you're delivering the date values to the client that corrupts it. We'd need to see a test case or more information to tell for sure.