RadDatePicker and timezones

[Ivaylo]

I have a RadDatePicker control. I select a date and submit the form. In the code behind, the datetime object is a date in UTC, that is not the same as the entered date. This is because the calendar uses internally a javascript Date object, which picks the locale of the client's browser and client-locale to UTC conversion seems to happen on the server. Is there a way to get the exact date that has been entered, regardless of the client settings of the user and the browser? I want the dates that my input receives to be treated just as entered without any timezone information or conversions. I want to use that date as UTC date in my logic, but since it is being converted automatically, I happen to operate with wrong data.

[Maria Ilieva]

Hi Ivaylo,

Thank you for contacting us.

I would suggest you to revise the following topic which elaborates on this matter.
I hope this helps.

Kind regards,
Maria Ilieva
the Telerik team

[Ivaylo]

Hi,

I guess you didn't understand my question. I am quite familiar with converting a datetime object from one timezone to another. The point of my question is that if I enter lets say 21.02.2011 14:45 as the selected date, I want to receive the same , but as it is in UTC. Instead, I receive it in some other timezone, and it is automatically converted to UTC with the other timezone's offset. I don't want that offset.

For example if I enter 21.02.2011 14:45,

and I want to use it in my code as 21.02.2011 14:45 (UTC)

insted the date on the clientside is 21.02.2011 14:45 (SOME OTHER TIMEZONE, -4h OFFSET FOR INSTANCE)

and it becomes when I access it server-side 21.02.2011 18:45 (UTC) because of the other timezone's offset.

I hope this makes it a bit clearer. The problem is not that I have to convert, but the mysterious timezone that comes with the date. If there is a standard way of determinig what is that timezone so I can do the conversion in a generic way, it will be fine.

[Maria Ilieva]

Hi Ivaylo,

The mentioned behavior is actually not related with our control functionality but is generic behavior which depends on the particular browser settings. The RadCalendar is returning Date type of object and its transformation to a date in the particular time zone depends on the browser side. So we could not change this logic as it is not directly related to our control.

All the best,
Iana
the Telerik team

[Ivaylo]

OK, I see. I will end up using a solution of my own here. As far as I am concerned, browser data or client-side information that comes with the date objects should be explicitly ignored, because, see, I may have the local settings of my browser in Argentina, but I want to work with a timezone that the web application specifies (if I am having a combo box with selectable timezones for isnstance). In general, sticking to a client timezone, or any timezone is not a good practice, especially if the application should implement it's own timezone handling. The browser timezone that comes with the date-inputs here brings a lot of confusion to the correct way of processing the timezones. I would suggest that you should handle this in a way that the DateTime object received on the server-side  has the same day, month, year, hour,minutes and etc as the entered date (therefore ignoring the timezone of the browser). In my solution I used the Microsoft.NET Ajax feature to format the date client-side into a string. This string I pass to the server, and since I know the format I used (yyyyMMddHHmmss) on the client, a call to DateTime.ParseExact did the work. It would be a good thing if in some of the upcomming versions of your controls this is fixed.

Best regards,
Ivaylo Slavov