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 

By the way, this update broke some of my CSOM code.  I don't know if this particular behavior change was intended.

I am using CSOM to add rows to the WebDataGrid.  Before, I could pass strings to the new row array, and that worked fine.  The WebDataGrid would handle them as dates.  Now, the server throws an error if I try to pass in a string.  To fix it, I have to turn all strings into proper Javascript Date objects.

This now throws a server error, where it didn't before: 

    var newrow = [
                     '11/12/2011'
                  ];
    rows.add(newrow);

This works:

    var newrow = [
                    new Date( '11/12/2011')
                  ];
    rows.add(newrow);

Question...  I notice that when converting the string to a javascript Date object, it is passing the time zone with the date.

What happens if the user's machine is in a different time zone with the server?  What will be saved to the database? 

My intention is to work with whole dates (time is irrelevant). 

Hi Rob,

Actually the intent of the bug fix was to solve an issue when the computer and server were in different time zones.  By passing the dates as strings, it is whatever the date is regardless of the timezone.  Day light saving and timezones won't adjust the date by hours or anything now. 
As for the issue you have where that code used to work, I will investigate it.  I'll let you know if a bug ends up being submitted on it.

-Dave 

Ok, it did used to work.  It's in how we convert the dates.  Right now the code expects a date.  But we know it should be a date, so we'll try to convert it.  It has been submitted as bug 95482.  This may or may not make it into the upcoming Service Release.

-Dave

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.

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