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 

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.

Rob

I am using 11.1.20111.2064.  I saw on this post that as of last week Infragistics is unsure if this is going to be in an SR or not, and I (like most of us) need to make it to meet our deadlines.  I thought about upgrading to 11.2, but I really didn't want to throw any more wrenches into the mix since this piece is going into production in the next few days. The last thing I need is to trash my deve environment right now. Especially since I have not seen any post from "them" :) that the fix is included in 11.2.

I agree with your posts, that this is a HUGE problem for anyone editing date/times on the grid. I saw the bug by "accident" in some of my final testing, else it would have gone out and trashed alot of data.  BTW, that last post where it captures the date string in javascript is the safest way reset the dates and times. The other way works if you just want the date (determining the offset time, and doing math to guess at the right value), and you don;t have to add a new field and muck up your datastores with these extra fields.

It would be nice to know when a version with the fix is going to be released, so I can plan accordingly.

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

Thanks

Jorge

Thanks for reporting back!  Glad to hear it!

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);

}