Question

I have a website that is hosted in a different timezone than the users using the application. In addition to this, users can have a specific timezone. I was wondering how other SO users and applications approach this? The most obvious part is that inside the DB, date/times are stored in UTC. When on the server, all date/times should be dealt with in UTC. However, I see three problems that I’m trying to overcome:

1. Getting the current time in UTC (solved easily with DateTime.UtcNow).

2. Pulling date/times from the database and displaying these to the user. There are potentially lots of calls to print dates on different views. I was thinking of some layer in between the view and the controllers that could solve this issue. Or having a custom extension method on DateTime (see below). The major down side is that at every location of using a datetime in a view, the extension method must be called!

   This would also add difficulty to using something like the JsonResult. You could no longer easily call Json(myEnumerable), it would have to be Json(myEnumerable.Select(transformAllDates)). Maybe AutoMapper could help in this situation?

3. Getting input from the user (Local to UTC). For example, POSTing a form with a date would require converting the date to UTC before. The first thing that comes to mind is creating a custom ModelBinder.

Here’s the extensions that I thought of using in the views:

public static class DateTimeExtensions
{
    public static DateTime UtcToLocal(this DateTime source, 
        TimeZoneInfo localTimeZone)
    {
        return TimeZoneInfo.ConvertTimeFromUtc(source, localTimeZone);
    }

    public static DateTime LocalToUtc(this DateTime source, 
        TimeZoneInfo localTimeZone)
    {
        source = DateTime.SpecifyKind(source, DateTimeKind.Unspecified);
        return TimeZoneInfo.ConvertTimeToUtc(source, localTimeZone);
    }
}

I would think that dealing with timezones would be such a common thing considering a lot of applications are now cloud-based where the server’s local time could be much different than the expected time zone.

Has this been elegantly solved before? Is there anything that I’m missing? Ideas and thoughts are much appreciated.

EDIT: To clear some confusion I thought add some more details. The issue right now isn’t how to store UTC times in the db, it’s more about the process of going from UTC->Local and Local->UTC. As @Max Zerbini points out, it’s obviously smart to put the UTC->Local code in the view, but is using the DateTimeExtensions really the answer? When getting input from the user, does it make sense to accept dates as the user’s local time (since that’s what JS would be using) and then use a ModelBinder to transform to UTC? The user’s timezone is stored in the DB and is easily retrieved.

Answer 1

Not that this is a recommendation, its more sharing of a paradigm, but the most agressive way I’ve seen of handling timezone information in a web app (which is not exclusive to ASP.NET MVC) was the following:

• All date times on the server are UTC.
  That means using, like you said, DateTime.UtcNow.

• Try to trust the client passing dates to the server as little as possible. For example, if you need "now", don’t create a date on the client and then pass it to the server. Either create a date in your GET and pass it to the ViewModel or on POST do DateTime.UtcNow.

So far, pretty standard fare, but this is where things get ‘interesting’.

• If you have to accept a date from the client, then use javascript to make sure the data that you are posting to the server is in UTC. The client knows what timezone it is in, so it can with reasonable accuracy convert times into UTC.

• When rendering views, they were using the HTML5 <time> element, they would never render datetimes directly in the ViewModel. It was implemented as as HtmlHelper extension, something like Html.Time(Model.when). It would render <time datetime='[utctime]' data-date-format='[datetimeformat]'></time>.

  Then they would use javascript to translate UTC time into the clients local time. The script would find all the <time> elements and use the date-format data property to format the date and populate the contents of the element.

This way they never had to keep track of, store, or manage a clients timezone. The server didn’t care what timezone the client was in, nor had to do any timezone translations. It simply spit out UTC and let the client convert that into something that was reasonable. Which is easy from the browser, because it knows what timezone it is in. If the client changed his/her timezone, the web application would automatically update itself. The only thing that they stored were the datetime format string for the locale of the user.

I’m not saying it was the best approach, but it was a different one that I had not seen before. Maybe you’ll glean some interesting ideas from it.