Hi Rob,

You can thank Microsoft for the problem since they do not serialize dates properly.  This was reported in bug 84041 and looks to be resolved in build 11.1.20111.2088, so it should be available in the next Service Release.  We changed how the dates are sent back and forth to the client (as strings, like you) to account for time zones and day light savings.

regards,
David Young 

Perfect, thanks!  I am ok because I have already converted my code...

However, if it doesn't make it into this upcoming SR, everyone's CSOM code will break when they install the SR, and they'll have had to diagnose and convert the errors before you release a fix in the next SR.  I am not sure it's a good idea to release a SR that you know will break someone's code, and inflict the pain on them of having to start from scratch figuring out what is wrong.

This is a workaround to deal with this problem of the grid changing editted date/time values.  BTW, the bug has NOTHING to do with different time zones between browser and server.  I am getting this bug while running locally against my server on same computer. 

If you have a date only field (no time) to deal with, then this will work well.

Mine is a little more complex than Rob's as I am dealing with both a date only field and a time only field. I will depend on the date only field to be editted at the same time as the time only field. If not I am screwed, but better than nothing.

Here is the code behind code (podMaster is the List object I bind the grid to).

// There is a bug in the webdatagrid, where it will subtract an hour at times. Possible daylight savings time issue.
// To remedy this, interrogate the date (since we know we just wanted the date), and if there is a time component,
// we assume it is due to this bug. Adjust the date field and the time field accordingly. The problem with this
// workaround is that if the do not edit both date and time, then we are going to corrupt the unedited field.
// My dates are nullable so need to typecast them

var delDate = (DateTime)podMaster.DeliveryDate;
var delTime = (DateTime) podMaster.DeliveryTime;
var tsTimeFromMidnight = new TimeSpan(24, 0, 0) - delDate.TimeOfDay;
if (tsTimeFromMidnight != new TimeSpan(0, 0, 0))
{
// We have an unexpected difference - the bug has bitten

if (tsTimeFromMidnight < new TimeSpan(11, 30, 0))
{
// Assuming that the bug subtracted tsTimeFromMidnight from date, so we need to add this back.
// Also assuming that if this field has the bug, then all datetime fields have the bug

delDate = delDate.Add(tsTimeFromMidnight);
delTime = delTime.Add(tsTimeFromMidnight);

else
{
// Assuming that the bug added tsTimeFromMidnight to date, so we need to back this out.
// Also assuming that if this field has the bug, then all datetime

delDate = delDate.Subtract(tsTimeFromMidnight);
delTime = delTime.Subtract(tsTimeFromMidnight);

}

}

// Combine the seperate date and time fields
var actualDeliveryDate = delDate.Date.Add(delTime.TimeOfDay);

Hope that helps someone until this bug is fixed.

A fix to the code I posted is required.  timespan(24,0,0) is not = timespan(0,0,0).  I now first check the TimeOfDay to 0:0:0.

To deal with the time field alone, I added the following workaround:

I added a new string field to my datastore (DeliveryTimeControl), and added it as hidden to the grid.  I then added the following to the aspx page / javascript and linke added the event to the grid. My DeliveryTime field is in index 10, and my DeliveryTimeControl is in index 15.

Jorge, what version are you on?

Infragistics sent me an untested build of 11.1 that fixed the problem for me.  But they sent it so close to the release of 11.2 that I wonder if 11.2 includes the fix.  You aren't on 11.2 are you?

Installing 11.2 might be worth a try.

I am very lucky that my application doesn't call for storing time values.

Have you submitted a ticket so that they know about the issue that persists with time values?

The same happens to time columns, but for some reason, the date value of the time is changed.  Arghh!  Quite frustrating.  Will have to strip out the time portion in javascript and compare them to see if they really changed!  Just tabbing through a time field, the _Editing_CallValueChanging() event has these values:

? eventArgs.get_currentValue().toString()

"Wed Nov 30 10:21:00 PST 2011"

? eventArgs.get_newValue().toString()

Very odd that webdatagrid chose to change the date portion of the time column form Nov 30 to Nov 10.  Happens to be my wife's birthday! 

They still need to do some more work on the date and time column editing.

One side effect I have noticed is that for date columns, the CellValueChanged Event gets triggered by just tabbing through a date field. 

Evaluating the  _Editing_CellValueChanging event, the eventArgs.get_currentValue() and eventArgs.get_newValue() are equal.  I imagine this is a side effect of the change that was made. 

I am currently using this code to bypass this behavior

function

wdg_Editing_CellValueChanging(sender, eventArgs) {

if (eventArgs.get_currentValue().toString() == eventArgs.get_newValue().toString())

eventArgs.set_cancel(

true);

}

Thanks for reporting back!  Glad to hear it!

Just wanted to confirm that I upgraded to 11.2 and this is no longer an issue.

Thanks

Jorge