[Isomorphic]

We've found and fixed the problem with the DateChooser (recent regression). The same underlying problem could cause the chosen date to be off by one month but never by one day so we think this might have been what you were seeing, and you may have been confused by MDY ordering. Please confirm with the next nightly build that both problems are fixed.

[jchajdiak]

We've found and fixed the problem with the DateChooser (recent regression). The same underlying problem could cause the chosen date to be off by one month but never by one day so we think this might have been what you were seeing, and you may have been confused by MDY ordering. Please confirm with the next nightly build that both problems are fixed.

I used nightly build from 1.6.2011 and I can confirm that calendar is now OK.

The problem with getting date+1 day when selecting date from calendar still remains.
For example when I click on 1st of june 2011 in calendar I get 06/02/2011 in date field. The timezone on my computer is UTC+1 with daylight saving (so now it's UTC+2). When I change my timezone to UTC, it's woking OK.

[Isomorphic]

Can you show a standalone test case for how you can reproduce this result?

[jchajdiak]

Can you show a standalone test case for how you can reproduce this result?

This is my test case:

import com.google.gwt.core.client.EntryPoint;
import com.smartgwt.client.widgets.form.DynamicForm;
import com.smartgwt.client.widgets.form.fields.DateItem;

public class Test implements EntryPoint {
public void onModuleLoad() {
final DateItem date = new DateItem("test");
date.setUseTextField(true);
DynamicForm form = new DynamicForm();
form.setFields(date);
form.draw();
}
}

[Isomorphic]

This has been fixed (try next nightly). Sorry about the confusion, our automated test for this covered a more complex scenario where there was no issue.

[jay.l.fisher]

SmartClient Version: SC_SNAPSHOT-2011-06-03/PowerEdition Deployment (built 2011-06-03)

I'm seeing an inconsistency in the time portion of Date fields that seems to be related to this. When using ValuesManager.getValueAsString() I get a string like "Sat Jun 25 2011 12:00:00 GMT-0500 (CST)". But when using Record.getAttribute() for a field with the same date value I get "Sat Jun 25 2011 00:00:00 GMT-0500 (CST)"

The time portion is noon in the first case but midnight in the second.

[Isomorphic]

While the time portion of a value from a field of type "date" is meant to be ignored, this is still a troubling symptom. However we can't seem to reproduce it - can you create a runnable test case?