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

.net-4.5 entity-framework-6 timezone


I've spent quite a bit of time on stackoverflow and the internet trying to determine what has been done in my situation. I am building a centralized line of business website that could span multiple timezones. Based on some valuable information here I have a plan in place to handle this.

Now to the issue I don't know how to solve. Kendo UI uses JSON to pass information back and forth and as far as I can tell the serializer cannot serialize a date to a specific time zone. I can serialize the date as UTC or have automatically convert it to local time using the DateTimeZoneHandling setting but that would be local time on the server. From looking at the code, I'm not sure I could even write a converter to do what I wanted. So far now if I send the date as UTC through and Kendo automatically converts the time to the browser's local timezone.

Assuming User Profile timezone = Browser Timezone seems a little scary for me and I wanted to see what stackoverflow suggests I do. Thank you in advance.

Technology MVC 5

Entity Framework 6

Telerik Kendo UI Controls

5/23/2017 12:31:14 PM

Accepted Answer

I was finally able to find this answer here that will allow me to write my own JSONconverter and convert to a specific time zone before it is serialized. I now have all of the dates being converted on the server side based on the timezone setting in the user profile.

5/23/2017 11:45:05 AM

Popular Answer

Unfortunately I don't know many of the tools you are using, but I know how I would handle timezones.

I would use UTC everywhere, except when displaying times (or rather: datetimes) and in user input.

I would let the browser's JavaScript do the conversion in output, using the browser's timezone. In input, the conversion can be done either client side or server side. In the latter case the timezone must be part of the information sent from the browser to the server. The UTC timezone on the servers should be set at a level as low as possible, and, if possible, in all components (OS, web server, DB...).

A user's preferred timezone is nonetheless useful for all cases where the timezone is not known (e.g., in email communications - but remember to always have the timezone in time formats).

There are times (no pun intended...) when the above is not easy or does not apply. E.g., a schedule (calendar), to which the user attaches the timezone they have in their head, not necessarily the browser's one. Another case is when the user's timezone has to be known for some computation that can not easily be done on the browser - in this case the server will have to get the timezone from the browser first. But most of the time (still no pun intented...) you can happily do without timezones (with UTC) except immediately before showing something to the user or immediately after getting something from the user.

Regarding your last paragraph: you will very soon run into trouble if you assume "user profile timezone = browser timezone".

Some last words of advice:

  • "Timezone" is an ambiguous term. It may refer to a fixed offset from UTC (like UTC+1), or to the rules for calculating this offset for any instant in a given area (like the timezone of Rome, Italy). Always use the second meaning (e.g., don't use the current offset for a date in the future or past, but correctly convert datetimes back and forth), and remember that both can change during a user's session.
  • Be careful not to handle "pure" dates as the midnight of the same day (and not as noon either - people in Samoa will thank you), because then the date can change when the timezone changes. In other words, don't attach time information to pure dates.

P.S.: By following a link of yours, I was happy to find that I totally agree with the closing remark of this answer (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