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 Veselina,
Thank you for the provided sample. I am currently investigating the behavior of the grid and the date column. I will come back to you with an update as soon as possible.
In the meanwhile if you have additional questions feel free to ask them.
The issue is represent because the DateDisplayType option of the columns wasn’t set. In the first grid the first date adds timezone property to the grid's data column and uses local timezone.
In order to make the two grid’s timezones equal set both grid configurations the DateDisplayType to DateDisplayType.UTC or to DateDisplayType.Local.
column.For(x => x.StartDate).HeaderText("StartDate").DataType("date").DateDisplayType(DateDisplayType.UTC);
In case you have additional questions don’t hesitate to ask them.
Thank you for your cooperation. This settings resolved the problem.
However I have difficulties with the igDatePicker control.Again, I'm using the MVC wrapper. I have modified my sample adding an example where the following behavior is observed:
There are two datepickers. From the MVC controller the two DateTime fields are set to values: viewModel.FirstDate = new DateTime(2018, 6, 13);viewModel.SecondDate = new DateTime(1976, 6, 13);
When the view is rendered there is a problem with the date DateTime(1976, 6, 13), which is displayed by the datepicker as 12.06.1976 23:00. The other date is displayed correctly. When the model is submitted without making changes to the dates - the correct dates come to the server.When I change the values of the datepickers to the date (dd.MM.yyyy) 01.01.1950 00:00 - again everything is okay.However when picking for example 01.07.1950 00:00 and submitting, the DateTime on the server is 01.07.1950 1:00:00I tried to experiment with the options EnableUtcDates and DisplayTimeOffset, but couldn't find a working solution where the whole roundtrip of the dates work, no matter which date is chosen.
Can you guide me how to resolve the issue?
igGrid_DateTime_Submit_modified.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.
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!