My server-side API exposes all dates and times in UTC and I want to display all dates and times to the user in UTC (not the browser's local time).I am attempting to use the ASP.NET MVC DatePickerWrapper to construct a DatePicker which will display dates and times in UTC.
I have used the following code in my ASP.NET Razor view:Html.Infragistics().DatePickerFor(d => d.MyDateTimeProperty).EnableUTCDates(true).ID("MyDateTimeProperty").Render()
When bound to a model in C# such that MyDateTimeProperty is 2015-04-10T00:00:00.000ZMyDateTimeProperty = DateTime.SpecifyKind(new DateTime(2015, 04, 10), DateTimeKind.Utc)
The view fragment is rendered as$('#MyDateTimeProperty').igEditor({ inputName: 'MyDateTimeProperty', value: new Date(2015, 3, 10, 0, 0, 0, 0), enableUTCDates: true });
This is incorrect because the date will be interpreted by the browser as a local time, not a UTC time. MyDateTimeProperty represents an unambiguous instant in timebecause its Kind is Utc, so it should be rendered to HTML and Javascript in a way that preserves this information.
When a browser executes this script it constructs a new Javascript Date object in browser local time. My browser is in the en-GB locale andthis date falls in British Summer Time (our daylight saving time) so I get 2015-04-10:00:00.000+01:00 i.e. 2015-04-09T23:00:00.000Z.The DatePicker then shows 2015-04-09 when I would expect 2015-04-10.
I use a collection of the same model objects to populate an Ignite UI grid. The data are retrieved using AJAX and the dates are correctly displayed in UTC.This is because the default JSON serialization in both ASP.NET MVC ("\/Date(1428624000000)\/") and ASP.NET Web API ("2015-04-10T00:00:00.000Z") preserves the instant in time.
Either of the following renderings would preserve the instant in time:
$('#MyDateTimeProperty').igEditor({ inputName: 'MyDateTimeProperty', value: new Date("2015-04-10T00:00:00.000Z"), enableUTCDates: true });$('#MyDateTimeProperty').igEditor({ inputName: 'MyDateTimeProperty', value: new Date(1428624000000), enableUTCDates: true });
Please would you suggest a work-around for this issue?
Kind Regards,
Merlin
Hello Merlin,
Thank you for contacting Infragistics!
I have done some looking into this matter and have some follow up questions concerning this matter.
As you describe the issue it is that you have dates on your server, and when you pass them to the client and set it to the igDatePicker it converts that date to local time? Is that correct? You want to date to display ignoring time zone so that no matter where you are the datetime will be the same?
Looking forward to hearing from you.
I'm going to use the ISO 8601 date time format below to be explicit about instants in time. .NET DateTime objects can be displayed in this format by calling .ToString("O") and Javascript Dates can be displayed in the same format by calling .toISOString().
This is not really a display issue. It is more fundamental. The issue is not with the Ignite UI DatePicker component. That works fine. The issue is with the way the DatePickerWrapper serializes a .NET DateTime object with Kind = DateTimeKind.Utc. More specifically, the issue is with ModelBase.JsonFromDateTime. It serializes 2000-05-01T18:00:00.000Z in this format: new Date(2000, 4, 1, 18, 0, 0, 0)
A browser with a UTC offset of +4 will construct a Javascript Date object with a value of 2000-05-01T18:00:00.000+04:00
A browser with a UTC offset of -7 will construct a Javascript Date object with a value of 2000-05-01T18:00:00.000-07:00
My issue is not that these dates are displayed differently (By default they will be displayed as 2000-05-01 18:00:00 in both browsers if enableUTCDates is false). It is that they are different instants in time and neither is the instant originally serialized on the server.
Regards,
Thank you for the update. I have done some further looking into this matter and have discussed this matter with my team. You could try generating the date in JavaScript instead of using the wrapper. Then Set enableUTCDates to false as enableUTCDates will modify the date to display in the local browser time.