CODEWITHSUNDEEP
c#asp.netwebformstimezone
ipohfly
ipohfly

Reputation: 2009

Force a particular Timezone across an application

A tricky situation here. Our application runs in a system that is set with a particular TimeZone (let's say Asia time). However a client request that his application to be run using Europe timezone.

Since our data are not stored in UTC, is there anyway we can set the locale in the application so that all dates displayed will be using Europe TimeZone? I understand that we can set the Culture info at the Web.Config but i'm not sure whether that can help set the TimeZone as well.

BTW our application is running using C# WebForm and MSSQL 2008 R2.

Upvotes: 2

Views: 4576

Answers (3)

RaSor
RaSor

Reputation: 877

How about changing locale?

CultureInfo currentCulture = Thread.CurrentThread.CurrentCulture;
if (currentCulture.Name != "sv-SE")
{
    // Change the current culture to sv-SE and serialize the date.
    Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("sv-SE");
}

// Do something with a date in swedish timeZone
var swedishNow = DateTime.Now;

// Restore back to the original culture, when finished
Thread.CurrentThread.CurrentCulture = currentCulture;

Upvotes: 1

Matías Fidemraizer
Matías Fidemraizer

Reputation: 64933

You should store your dates with DateTimeOffset:

Represents a point in time, typically expressed as a date and time of day, relative to Coordinated Universal Time (UTC).

Using DateTimeOffset has great advantages, as these dates are easily convertible to any timezone without losing the offset where the event happened (i.e. storing some data in some moment in time).

As Jon Skeet suggested in a comment in my answer, a time zone identifier should be stored along with the DateTimeOffset in order to have the full date+time information and make it fully convertible.

In the other hand, you may not store data in a particular time zone but with a DateTimeOffset as is with the whole time zone identifier, and later you'll convert it to the required time zone depending on user profile's or application-wide time zone and/or culture setting in the application layer.

Finally, you can convert such DateTimeOffset using this TimeZoneInfo.ConvertTime(DateTimeOffset, TimeZoneInfo) overload.

Upvotes: 1

Jon Skeet
Jon Skeet

Reputation: 1499760

How your data is stored is entirely separate to how you choose to display it. Assuming the dates and times are meant to represent fixed points in time (rather than floating "local" times) I would try to write as much of the application as possible with DateTime values in UTC. When you retrieve data, convert it from your "storage time zone" if you need to (you haven't said which zone your data is stored in) and convert it back when you store it. When you display it, display it in whichever time zone you need to.

You don't need to set this at a global level as far as .NET is concerned - you can have an application-wide configuration setting (if you really want to) and "helper" code to convert it whenever you need to display. I would do so very explicitly though: you really don't want conversions happening implicitly when it comes to time stuff.

(I'd also mention that my Noda Time library may come in useful as a clearer API when it comes to dates and times. I'm biased, of course. I'd also suggest migrating to storing everything in UTC if you can... and only where appropriate, of course.)

Upvotes: 2

Related Questions