MVC Handling Timezones and JSON Serialization - How to Convert to Specific Timezone

.net-4.5 entity-framework-6 timezone


I've spent a fair amount of time researching what has been done in my scenario on stackoverflow and the internet. I'm constructing a central line of business website that might operate across several time zones. I have a strategy in place to manage this based on some very useful information found here.

  • The user profile will include timezone information.
  • Dates will all be kept in UTC.
  • Upon retrieval from the database, EF sets DateTimeKind to UTC (Can customized properties be protected from being overwritten by EntityFramework 4?).
  • To convert UTC time to local time, create some HTML helpers for DatePickers and DateDisplays (based off user timezone)
  • On form postings, use Model Binding to change the time zone back to UTC.

Here's the problem I don't know how to fix. According to what I can determine, the serializer cannot serialize a date to a specific time zone when Kendo UI utilizes JSON to transfer information back and forth. I can serialize the date as UTC or use the DateTimeZoneHandling feature in to automatically convert it to local time, but it would be local time on the server. I'm not even sure I could construct a converter to achieve what I wanted after looking at the code. As of right now, Kendo automatically changes the time to the local timezone of the browser if I send the date as UTC using

I wanted to know what stackoverflow advised since assuming User Profile timezone = Browser Timezone seems a little dangerous to me. I want to say thank you.



Instance Model 6

Kendo UI Controls by Telerik

5/23/2017 12:31:14 PM

Accepted Answer

The solution that will enable me to create my own JSONconverter and convert the data into a specified time zone before it is serialized was eventually found here, at As of right now, all dates are being converted on the server side based on the user profile's timezone selection.

5/23/2017 11:45:05 AM

Popular Answer

Unfortunately, I am unfamiliar with many of the technologies you are employing, but I am aware of my approach to timezones.

Except for the display of times (or, rather, datetimes) and user input, I would use UTC everywhere else.

I would let the browser's JavaScript do the output conversion using the timezone of the browser. The conversion for input can be carried out either client-side or server-side. In the latter scenario, the timezone must be included in the data that the browser sends to the server. It is recommended to set the UTC timezone on the servers as low as feasible and, if possible, in all components (OS, web server, DB...).

However, in all situations when the timezone is unknown, a user's preferred timezone is helpful (e.g., in email communications - but remember to always have the timezone in time formats).

The aforementioned is sometimes difficult to execute or does not apply (no pun intended). For instance, a schedule (calendar) that the user, rather than the browser, assigns their own timezone to. Another situation is when the server needs to obtain the user's timezone from the browser in order to do a calculation that cannot be done simply on the browser. However, for the most part (again, no pun intended), you can get by without timezones by using UTC, with the exception of right before revealing something to the user or right after receiving something from them.

Regarding your final sentence, if you make the assumption that "user profile timezone Equals browser timezone," you will quickly run into problems.

Final words of wisdom

  • The phrase "timezone" is vague. It may refer to a constant offset from UTC (such as UTC+1) or to the formulas used to determine this offset for any particular instant in a specific region (like the timezone of Rome, Italy). Always use the second meaning and keep in mind that both can vary over a user's session. For instance, never use the current offset for a date that is in the past or future.
  • Don't treat "pure" dates as midnight on the same day (and don't treat them as noon either – Samoans will thank you for it), as the date may vary if the timezone changes. In other words, avoid adding time details to simple dates.

P.S. : After clicking on one of your links, I was pleased to see that I completely concur with this response's final statement (by someone with more SO reputation than me)

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow