CODEWITHSUNDEEP
c#asp.net-mvcdatetimelocalizationtimezone
Ross Gledhill
Ross Gledhill

Reputation: 662

ASP MVC - Handling DateTime Localization with Timezones and Culture

I'm currently considering approaches for implementing DateTime localization, taking into account a users timezone and user culture to decide the local time and date format for our MVC4 application.

The aims (if possible):

  1. Convert a users local DateTime to UTC dates for use on Controllers and the Database
  2. In all ViewModels/JsonResults, convert UTC to a users local DateTime and format for their culture in for use in views and for use in JSON feeds for third party controls

Users in our system all have accounts, and they have specifically set their Timezone and Culture settings, so I will always have access to those elements.

Local -> UTC (Solved)

For 1. I have a Custom Model Binder that takes the users local time and converts the time to UTC, which works as expected.

UTC -> Local

For 2. I'm not sure what the best way to tackle this. I really want to intercept all of the DateTime properties, and format the value from UTC to a users local time/culture before they're returned to the View or returned as a JSON object.

Can is there a generic way I do this using something like an ActionFilter? It would be great if I could find a way to do this in one place that would format DateTimes for use in both my Views and JSON results.

I know I could split this out, and do this in Display/Editor templates, but the problem I then have is then the UTC dates being returned in the JSON feed for Third party controls.

Upvotes: 2

Views: 1766

Answers (1)

Matt Johnson-Pint
Matt Johnson-Pint

Reputation: 241450

A few points:

  • Yes, you could use an action filter, but that would be making the assumption that everywhere in your application needed to work the same way. That might not always be the case.

    For example, perhaps one of your controllers is used by an administrative user who might see a value presented in the user's time zone instead of their own.

    Or perhaps one of your screens works with scheduling of future events. In these cases, it makes sense not to store in UTC or convert to the user's time zone - but to persist the data in the original time zone of the event.

  • In my MVC applications, I prefer to have full control over this in the controller and/or the model. If I want a value converted to a particular time zone, I manipulate the model's properties in the controller before returning it.

  • You might consider using a DateTimeOffset instead of DateTime in your models and controllers. This will make things a bit easier when it comes to understanding how different values relate to each other and to UTC. Offsets can be persisted, but DateTimeKind is hidden away and often gets lost. See also DateTime vs DateTimeOffset.

  • If you are storing in a DB such as SQL Server, you could also use datetimeoffset there. Sometimes that makes sense, and sometimes it still make sense to store a datetime or datetime2. Consider your options and choose what works for you.

  • Culture really only matters for regular views where you'll be formatting for the user. The JSON response should (preferably) be ISO8601 formatted, including the offset. It should use the InvariantCulture.

Upvotes: 1

Related Questions