Hey there!
We have problems with igGrid updating when there are columns of type date.We are setting up the grid using the MVC wrapper and the Updating feature is enabled with EditMode=GridEditMode.Row. The editor type of the date column is set to ColumnEditorType.DatePicker.
We manually submit the changes by serializing the transactions to string with the function "transactionsAsString" and send them to the server. However depending on whether the grid has some data or is initially empty - the date is sent to the server with different time component:
When we load a grid with some records in it and we update a row setting the date to 1991/07/18, when I inspect the grid transactions the date is "Thu Jul 18 1991 03:00:00 GMT+0300 (Eastern European Summer Time)". Thus the serialized date sent to the server as part of the transaction is "1991-07-18T00:00:00.000Z"
When however the grid has no data and we add a new row picking the same date, then the date in the transactions object is Thu Jul 18 1991 00:00:00 GMT+0300 (Eastern European Summer Time) and what is sent to the server is 1991-07-17T21:00:00.000Z.
With older versions of IgniteUI (16.2) the described scenario worked without any problems with dates.
I have attached a sample project demonstrating the problem.
What causes this behaviour and how should we set up the grid and process the transactions (client and server-side) so that dates will always be sent with the same time component (either UTC or local, but not mixing them up)?
igGrid_DateTime_Submit.zip
Hello,Thank you for your guidance for resolving the problem. I managed to set up a working sample making these changes as you suggested:
1. The DateTime objects passed to the DatePicker are with Kind=Utc2. Explicitly setting DisplayTimeOffset to 0.3. Adding a custom model binder for DateTime where I used: DateTime.ToUniversalTime()
If I have additional problems I will open a separate topic.
Hi, Veselina.
The other option you have is in your sample (before my changes) is to delete DisplayTimeOffset setting, instead of setting it to null. Can you try this also?
Regards,
Nikolay Alipiev
I hope that I will be able to help you with my answer. Thank you again for using our product!
I think we are experiencing the same thing as you and I will share some details to ensure we understood you correctly.
We are currently located in Bulgaria, which is UTC+03:00. The day light saving time was introduced in our country in 1979, that is why when in the console we type:
new Date(1976, 5, 13, 0, 0, 0).toString() the result is "Sun Jun 13 1976 00:00:00 GMT+0200 (Eastern European Standard Time)".
For any year after the 1979, the result is +0300 during summer time. Taking the date that is in your solution:
new Date(2018, 5, 13, 0, 0, 0).toString() the result is "Wed Jun 13 2018 00:00:00 GMT+0300 (Eastern European Summer Time)"
This is the way the Date object is behaving in the browser and because the Ignite UI editors are using the JavaScript Date object internally, the same is valid for them.
Here you can see the following paragraph Local observations and search if you are going to find specifics for the country you are currently located.
However the last question is not related directly to that. Let me share some observations beforehand.
I've changed your sample I little bit. Please see the attached file.
First I'm creating the date on the server in UTC. On my machine (server-side), which is +03:00, I create UTC date, and it ignores server time zone. This is recommended - to create, transfer date in UTC format, and only show local date or specific date with defined offset on client browsers.
viewModel.FirstDate = new DateTime(2018, 6, 13, 0, 0, 0, DateTimeKind.Utc);
viewModel.SecondDate = new DateTime(1976, 6, 13, 0, 0, 0, DateTimeKind.Utc);
So we created the date in UTC format, and editor wrapper will send it as UTC also. You can see this if you examine the script tag rendered just after the HTML input in the browser.
You can do one thing more - to set enableUtcDate of the editor to true, this will also ensure that client-side editor will save the date and send it back to the server in UTC format. As I said this is recommended and in this case is not related to the way date is displayed in the editor itself.
However I've also set the displayTimeOffset to 0, so that I see UTC time in the editors. Of course in your case you can set it to 120, or leave it undefined and any client-side browser will show it according to their time zone.
You can see that in that case both dates 1976 and 2018 are showing same dates.
Everything now is in UTC but if you submit a new date, then on the server it arrives with some offset inside the TestSubmit method. And this is because MVC is receiving the date in UTC, but taking into account server-side offset it automatically transforms it. Here there is StackOverflow post about this, which says that you need to manually convert to Universal Time, the date that MVC has modified. Please see the attached sample and I will wait for your feedback.
Best regards,
Software Developer
7607.igGrid_DateTime_Submit.zip
Hello,Thank you for your reply and sorry for my late response. I'm testing on my development computer where the timezone in the regional settings is UTC+02:00So I set the option to .DisplayTimeOffset(120)
This time however the initial dates from the previous sample: 13.06.2018 and 13.06.1976 are displayed one hour behind (12.06.2018 23:00) but when the form is submitted without making any changes to the picker values - the correct values are bound to the DateTime properties of the view model in the POST method.
If the initial values are 13.11.2018 and 13.11.1976 - they are displayed correctly in the picker and bound correctly in the POST method. If I pick for example 01.07.2018 00:00, then what comes to the server is 1.7.2018 1:00:00.It looks like the difference is related to Daylight saving time
Can you reproduce this behaviour when you set DisplayTimeOffset(120) in my previous sample?
I'm still unable to overcome this problem with using dateTimePicker with MVC.
Hello Veselina,
The behavior that you describe is caused by the regional settings of the server you are using (GMT+0300, most probably).
You can set
.DisplayTimeOffset(180)
Another option is to change the regional settings of the server to the zone that you are targeting.
Please, let us know if this is not a valid approach for your project so that we would be able to investigate it further.
Best regards!