My users have been reporting since yesterday that dates they enter into the WebDataGrid are losing a day when saving to the database.
On closer inspection, these date/time fields are losing 1 hour. For example, if a user enters 11/7/2011 into the WebDataGrid, 11/6/2011 11:00PM will be stored to the database, and the users then sees 11/6/2011 displayed in the grid as his saved value. This occurs regardless of the EditorProvider used... This even happens if you use the TextBox provider.
And this began recently, oddly corresponding to Daylight Savings Time.
I have found a very clumsy workaround. If you change your SQL statement so that it converts DateTime fields to VarChars, the WebDataGrid won't corrupt the date.
I have opened a support ticket CAS-77072-NSTXZT, but have also posted the issue and the workaround here, for the benefit of other users.
I consider this issue to be critical, since it is corrupting data.
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.
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 fieldsvar actualDeliveryDate = delDate.Date.Add(delTime.TimeOfDay);
Hope that helps someone until this bug is fixed.
Rob
What was your workaround for this bug? I am having the same issue. If I edit other fields on the same row as the date, no problems, but if I edit the date, it loses an hour when it posts back to the server.
Thanks
Jorge
Replying to follow the post. We're having the same issue.
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.