[Isomorphic]

If what you're saying is that the date is transmitted to the server in GMT, this is true and won't change (it's a widely acknowledge best practice). If you think there's still an issue with setting the display timezone, let us know.

[lazinskip]

Could it be configurable ? (conversion to GMT or from GMT). Something like DateUitl.setConvertToGmt(boolean) method ?. If my server stores datatime in local time I have to convert all incoming and outgoing datetime values.It would be much easier to developers if they can control this behaviour.

[romain.vdk]

If what you're saying is that the date is transmitted to the server in GMT, this is true and won't change (it's a widely acknowledge best practice).

Could it be configurable ? (conversion to GMT or from GMT).

Ok, if you say that the time sent to the server is always in any case in GMT, there is no bug here, the code I wrote adds or remove the timezone to the hour to match the GMT correction.

But I have the same question as lazinskip : Could it be configurable ?

[lazinskip]

Hi romain.vdk, could you give sample code how you remove or add timezone to the hour to match the GMT correction (on server side) ? I think my solution is not proper (example of offset removal):

	Calendar kal = Calendar.getInstance();
	SimpleDateFormat sdf = new SimpleDateFormat("yyyy-M-dd'T'HH:mm:ss");
	kal.setTime(data);
	kal.add(Calendar.HOUR_OF_DAY, -2);
	return sdf.format(kalendarz.getTime());

where data is date from database table (in local time) and my offset is +2 hours from GMT.

[romain.vdk]

Just use the DateUtil I posted, in client mode
Then, to send the date just do the following :

c.addCriteria("departureToDate",DateUtils.getTimeZonedDate(departureDateItem.getToDate()));

[Jackie_W]

Other threads on this have ended with the conclusion that there is no bug and the setDefaultDisplayTimezone API works properly. If you think there's an issue, try creating a standalone test case.

I have no idea which thread you refer to. I have searched many threads and most of them don't give a conclusion. Could you paste some urls?

[oddjobdev]

Try using DateTimeItem instead of DateItem if you are looking for setDefaultDisplayTimezone to take effect. That was our issue.

[stonebranch1]

Struggling with the same issue here.

We have a form that the users can enter a list of "dates" (not "datetimes")

ListGridField dateField = ...
dateField.setType(ListGridFieldType.DATE);

The user in say PST selects say July 1st, 2014 and when the server (running in EST) gets the data object, the date is now June 30th, 2014 due to the time zones and the date having set the time as 00:00 PST which is now the previous day in EST.

What would be the best way to solve this problem?

[Isomorphic]

Anyone who believes there are framework issues here should take an extremely close look at the Date and Time Format and Storage overview.

We get a steady stream of false "bug reports" in this area.

If you really, really think you've found a bug, please put together a minimal, ready-to-run test case, and please do your best to ensure it doesn't contain any of the common mistakes covered in the above overview.

[stonebranch1]

I have read that documentation several times but it is lacking in some details:

""date" handling

Fields of type date are considered to be logical Dates with no time value, such as a holiday or birthday. In the browser, values for "date" fields are stored as Date objects, but when formatted for display to the user, they are typically displayed without any time information.

When using the Smart GWT server framework, "date" values are automatically transmitted with year, month and day preserved and time value ignored.

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.

The DateUtil.createLogicalDate() method may be used to create a new Date object to represent a logical date value on the browser.

System wide formatting for dates may be controlled via the Date.setNormalDisplayFormat and Date.setShortDisplayFormat methods."

Is this recommending we send dates as formatted String values such as YYYY-MM-DD?

Here is my problem plain and simple:
- Server is running in EST time zone and I send a Date object from the server to the client. The actual object is a java.util.Date that inherently has a time component that yes I would like to be ignored. Lets say I send over the date that represents 2014-07-20 00:00:00 EST. So this java date object represents July 20th.
- my client browser is running with time zone PST (3 hours behind EST) and when that java Date object I sent from the server shows up in the UI it is now July 19th due to the timezone difference.
- How should I be sending dates from the server to the client to avoid this problem since sending a Java Date object has this problem? Can I not use a Java Date object or must I format that Date object on the server to just "YYYY-MM-DD" and send the value over as a String instead of a Date?

If so, if the datasource has defined the field as a Date, what happens then? Will the client send over Date objects or Strings and will I have the same issue coming the other way client -> Server.

I use customDS via DMI as well as RPC calls where appropriate.

For Example:

I have a date widget on my form and when I put in April 1st 2014 on my EST client this is what is sent in the request as part of the data object:
date:new Date(1396368000000),

From my PST client the same date of April 1st 2014 sends over:
date:new Date(1396378800000),

if you compare those two dates in EST they are:
Date of 1396368000000 = Tue Apr 01 12:00:00 EDT 2014
Date of 1396378800000 = Tue Apr 01 15:00:00 EDT 2014

You can see the problem here since the dates ARE actually different and could result in different days based upon the timezones and the actual time. If I run this test at 1am EST the date will actually be different.

[Isomorphic]

Make sure your DataSource fields are declared as type:"date" or "datetime" according to whether you want time preserved or not.

If you think you've found a bug, produce a clear, runnable test case and we'll take a look. We can't do anything with some anecdotes about code we can't see.

[stonebranch1]

Yes our datasource field is defined as a Date:

        <field name="date" type="date">

Could you tell me why the RPC calls contain 2 different date values for the same date field selected from a "DateItem" ui component when the client are in different Timezones?

Is there something I should be doing that would prevent that?

Thanks

[Isomorphic]

No, we definitely can't, because we don't have any of your code (hint, hint).

Nor do we even know what version you're running.