2

The only thing i know is, that DateTime should always be stored in UTC, but while displaying or getting the input it has to be the logged in User's local time.

This is to mitigate the timezone issues.

Any standards/best practices, where i have to touch minimum part of the already developed code base?

While getting a request, i can use ModelBinders (Asp.Net MVC). But what should i intercept to modify the DateTime types, while rendering out the response?

Any help will be appreciated ....

Mathew Thompson
  • 55,877
  • 15
  • 127
  • 148
sandeep
  • 149
  • 1
  • 12
  • I will have to. There is a feature where user interact, send message and all. And the users can be different time zone based. So i have got to store it in UTC, and diplay in local format. – sandeep Apr 24 '13 at 10:04
  • @AdamHouldsworth switching locales affects string formatting, but doesn't have anything to do with converting for different time zones. If he wants to record a specific moment in time, then it must either be a UTC DateTime, or a DateTimeOffset. Otherwise there is ambiguity. – Matt Johnson-Pint Apr 24 '13 at 12:17
  • @MattJohnson Apologies, I was getting my wires crossed with something else. – Adam Houldsworth Apr 24 '13 at 12:26
  • @MattJohnson Come to think of it' I'm still fairly certain you don't necessarily need to store it in UTC, you just need to realise that the date time is locale specific. I've just tried it locally storing a date in BST and reading it from a PST client, initially the date is still BST, but calling `ToLocalTime` correct it to PST. That said, standardising on UTC with local time probably avoids future headaches. – Adam Houldsworth Apr 24 '13 at 12:40
  • @AdamHouldsworth - If you store in local time, you also have to store the offset. Otherwise, daylight savings fall-back transitions are ambiguous. For example, in US Pacific Time, if you just store Nov 3rd 2013 1:30 AM - there is no way to know if that is PST or PDT. You must also store the -7 or -8 offset. The .net/sql `DateTimeOffset` type is perfect for this. – Matt Johnson-Pint Apr 24 '13 at 13:17
  • 1
    @AdamHouldsworth See also: http://stackoverflow.com/questions/4331189/datetime-vs-datetimeoffset – Matt Johnson-Pint Apr 24 '13 at 13:17
  • @MattJohnson Ah yes I see. Thanks for the link, I'll have a read. – Adam Houldsworth Apr 24 '13 at 13:18

2 Answers2

1

If your system has users, a good idea is to set the culture code against those users.

That way, on your base controller, you can override action executed and set the user's culture on the thread. Something like:

protected override void OnActionExecuted(ActionExecutedContext filterContext)
{
        if (currentUser != null) //user your user object
        {
            Thread.CurrentThread.CurrentCulture = new CultureInfo(currentUser.Culture);
            Thread.CurrentThread.CurrentUICulture = new CultureInfo(currentUser.Culture);
        }
        else
        {
            Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB");
            Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-GB");
        }
}

Then whenever you're using your DateTime objects, you can use ToShortDateString:

string localistedDate = yourDate.ToShortDateString();

Or if you don't want the short format, you can use ToString with your own format, passing in the culture on the thread

Mathew Thompson
  • 55,877
  • 15
  • 127
  • 148
1

Since you are storing UTC times, you will also want to convert that to the users time zone using either the TimeZoneInfo class, or NodaTime depending what kind of time zone information you have.

Depending on your scenario, you might want to use the standard IANA/Olson time zone database instead of the Microsoft Windows one. See the TimeZone tag wiki for details.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575