Timezone adjusting date issue

[sharper]

Hi,

Sorry for asking a question that has been asked many times on the forum, but I've read all the posts, tried a few recommendations and I'm still scratching my head.

The issue is with dates returned from the database with midnight timestamp (00:00:00) and how they are adjusted by the client, which is a big issue if the client is a timezone with a negative offset since it adjusts the date to T-1. Our users are in located in EST and I am unable to stop the date adjusting to the EST timezone despite trying several methods.

I have tried:
1. Stop the client adjusting the timezone by setting default timezone
2. Format the date on the client using a different time zone for
3. Adjust the date to a different timezone on the server with -ve offset.

But none of these methods work. In more detail:

For 1 I have tried the following onModuleLoad()

DateUtil.setDefaultDisplayTimezone("+00:00");
DateUtil.setAdjustForDST(false);

When I select a list grid and output what value is selected I get the following in my Console:

08:37:24.767:MUP7:WARN:Log:Selected event with id: 4671554, selectedEventDate: Sun Apr 14 20:00:00 GMT-400 2013

Corresponding value in the RPC:

"eventDate":"2013-04-15T00:00:00+0800"

So that doesn't work.

OK, so I thought I'd try 2 above and set the format in the ListGrid so that it converts the date to a different timezone using a cell formatter, however, GWT's DateTimeFormatter does not support time zones.

So I then tried 3 above by setting the timezone for each date field on the server so it was set to some -ve offset and I removed the default timezone in CREED, but it still adjusts:

Console RPC:

eventDate":"2013-04-04T00:00:00-0400

List Grid select gives shows value has been adjusted:

selectedEventDate: Wed Apr 03 20:00:00 EDT 2013

Please let me know if any of these are along the right lines.

Thanks
Stephen

[Isomorphic]

Take a look at the Date Format and Storage overview, and, if you think there's a framework issue here, explain what it is based on the details in this overview; much of what you're doing below (just looking at String values) is not the correct way to figure out what the time values are and whether they've shifted.

[sharper]

Thanks for the link to the documentation - I had missed this.

Having read the documentation, one thing that stands out is this:

When sent or received in XML or JSON, date field values should be serialized in the XML Schema date format - YYYY-MM-DD - are expected to be received in the same format. ***Any time value present for a "date" field is ignored.***

Likewise this does not hold true:

If you declare a field as type "date" but values you provide actually contain specific hours, minutes and seconds, these will not be preserved. ***The system will discard or reset the hours, minutes and seconds in the course of serialization or editing***

In my code I have declared these fields as Dates, yet the fields are definitely being adjusted based on the time and timezone.

DS:

DataSourceField eventDateField = new DataSourceField(EVENT_DATE, FieldType.DATE, "Event Date");

Console RPC:

"eventDate":"2013-04-19T00:00:00-0400"

Value of eventDate on ListGrid selection:

selectedEventDate: Thu Apr 18 20:00:00 EDT 2013

Am I interpreting this incorrectly? It would certainly help me if SmartGWT worked this way so I do not have to create a server side object as a wrapper for a Date object to determine if it is a date or a datetime when I'm doing my serialisation.

Thanks,
Stephen

[Isomorphic]

We don't know what version you're using, but this might be a behavior of an older version. The docs you were linked to are for the latest version.

Best fix is to avoid outputting spurious time values for date fields. This is something the server framework does automatically.

[sharper]

I'm using: 3.0-p20120718, from Console:

SmartClient Version: v8.2p_2012-07-18/LGPL Development Only (built 2012-07-18)

(not sure I like the look of "Development Only"!)

I've made a fix on my server so that Dates are sent in the way specified in the documentation and things are working fine now - thanks for your help.

Steve