Hi Elizabeth,

Thanks for the links, they were helpful. I'm still having a tough time with this though. I can't seem to get the results that I am looking for. To make things easier, I tested this with my server and client in the same timezone, UTC-05:00. The date from my server is 4/1/2013 12:00:00 AM. I'm using C# MVC to generate the grid control and then I'm using JsonConvert.DeserializeObject<List<Transaction<T>>>(a_Controller.HttpContext.Request.Form["ig_transactions"]) to deserialize the data on the server side, so I'm not sure if that has something to do with the issue I am seeing. Also, I'm using a row edit dialog to update the data and a ColumnEditorType.DatePicker.

I tried using the DateDisplayType.UTC as mentioned in the article and below are my results (I'm showing this for my sanity as well). Previously, I tested this without using the DateDisplayType setting and the results from those tests are not included, but that didn't work either (I can provide those tests if needed though). Below, where it says "CHANGE RESULT", this is the resulting date that is passed back to the server when I used the DatePicker to change the date to 4/2/2013 and then back to 4/1/2013. For the "NO CHANGE RESULT", I didn't make any changes to the date and just hit "Done" to submit my changes.

gridModel.EnableUTCDates = true;
updatingSetting.DateEditorOptions.EnableUTCDates = true;
column.DateDisplayType = DateDisplayType.UTC
CHANGE RESULT: 4/1/2013 4:00:00 PM
NO CHANGE RESULT: 4/1/2013 12:00:00 AM

gridModel.EnableUTCDates = false;
updatingSetting.DateEditorOptions.EnableUTCDates = true;
column.DateDisplayType = DateDisplayType.UTC;
CHANGE RESULT: 4/1/2013 4:00:00 PM
NO CHANGE RESULT: 3/31/2013 8:00:00 PM

gridModel.EnableUTCDates = false;
updatingSetting.DateEditorOptions.EnableUTCDates = false;
column.DateDisplayType = DateDisplayType.UTC;
CHANGE RESULT: 4/1/2013 12:00:00 PM
NO CHANGE RESULT: 3/31/2013 8:00:00 PM

gridModel.EnableUTCDates = true;
updatingSetting.DateEditorOptions.EnableUTCDates = false;
column.DateDisplayType = DateDisplayType.UTC;
CHANGE RESULT: 4/1/2013 8:00:00 PM
NO CHANGE RESULT: 4/1/2013 12:00:00 AM

So I can't seem to get a 4/1/2013 12:00:00 AM date back to the server. Is there something I am missing?

Thanks,

Paul

Hello Paul,

If you are using EF, your model's DateTime-s are probably loaded as DateTimeKind.Unspecified, which may provide some inconsistent results as Newtonsoft.JSON doesn't send offsets for such objects. The client then receives an incomplete ISO formatted date that it interprets differently between browsers. If you are sending the data through a controller decorated with a GridDataSourceAction attribute or just sending it with the view, the MVC helpers alleviate that by forcing Newtonsoft.JSON to interpret such DateTime-s as UTC at least ensuring all clients interpret them in the same way,  however, this might not be correct for your app.

It's a pretty complicated topic overall and earlier versions did more work under the hood to cover basic scenarios while failing in other specific use-cases.

One thing you could try out just to give you an idea of how it should behave is to provide a hardcoded object for your data with the DateTime-s specified as UTC. Then the roundtrip should be consistent. You could also try not specifying DateDisplayType for the column leaving the MVC wrapper to manually handle offsets showing Dates as they would be displayed on the server (this will again only work if you are passing your model through the MVC helpers).

In any case you don't need to specify EnableUTCDates for the DatePicker as it is currently only a communication option and the DatePicker inside the grid doesn't send requests directly to the server for it to matter.

I will try to isolate a sample in which the behavior is exactly as you define it so I can provide you with more information on how to resolve this.

Best regards,

Stamen Stoychev

Hi Stamen,

You're right, and it is being loaded as DateTimeKind.Unspecified. We are not currently using GridDataSourceAction though (I can't remember why, but I'm pretty sure this has to do with the fact that our Url to get the data requires some extra parameters in addition to path and layout. So GridDataSourceAction doesn't work for our situation). We are currently using GridModel.GetData(path, layout) to get the data. Is there a way to force this method to interpret the DateTimes as UTC?

We did as you suggested and hard-coded this to be specified as UTC. This does make sense on the "view" side; however, I think there is still something that is off when the value changes in a RowEditDialog. When changing the value using the datepicker, the date that is submitted to the server is still '4/1/2013 8:00:00 PM' when EnableUTCDates is true or false.

An isolated sample would be helpful. If you are unable to duplicate this, then please send me basic sample using an MVC grid with a RowEditDialog and I think I should be able to duplicate it as long as I have an initial sample.

Thanks,

Paul

Hi Stamen,

I've attached an example of what I am seeing. The first two rows have a Start Date column set. Can you please let me know what settings I should be using so that the date doesn't change? To duplicate this, edit the first row in the grid. Change the date from 4/2/2013 and then back to 4/1/2013. Then debug the server code. In HomeController.SaveChanges_Generic, there is a line: 'Console.WriteLine(column.Value);'. Just put a break-point on that line. You'll notice that the time changes when you submit. Can you provide the settings needed to get this example to work without the time changing?

Thanks,

Paul

Thanks for the update, this appears to be working in our main solution when using the infragistics.ui.editors.js from the GitHub. We'll use that code for now and we don't need a private build.

One other thing I just wanted to mention is that we found a situation where the time was still changing when we set the MinValue of the DateEditorOptions. This would only happen in cases where the date was actually typed in (and the datepicker was not used), even if the validation wasn't triggered. We originally had this set to updatingSetting2.DateEditorOptions.MinValue = new DateTime(1900, 01, 01);

After changing this to updatingSetting2.DateEditorOptions.MinValue = new DateTime(1900, 01, 01, 0, 0, 0, DateTimeKind.Utc); , this worked as expected as well.

Thanks for your help with this.

Thanks,

Paul

Hello Paul,

You are welcome!

This probably goes back to how DateTimeKind.Unspecified is not consistent when deserialized between different browsers. Generally speaking such DateTime-s are not really points in time and should be given context on an application level to mean anything. Regardless, I'll speak with my colleagues that develop igDatePicker and see if their opinion is that we can improve this scenario. As you have found (and I verified) that specifying DateTimeKind for this option's value is a clean solution I will not log any work items internally for this at the moment. I'll let you know should this change.

Thank you for using Ignite UI!

Best regards,

Stamen Stoychev