Default time zone per user, set in the business logic

I have an application where all the DateTime's are always the time of the server. That means one time zone. The idea is to make the application compatible all over the world. The first step is to convert all the stored DateTime's in the database to UTC, that's no problem. Second step is to assume a timezone for the user (based out business logic), and to use as a default for displaying and parsing user input. Furthermore it would be nice if methods li开发者_如何学Pythonke DateTime.Now and other method calls that construct datetimes without explicit time zone/region information would also assume this time zone/region.

The idea is to assume a time zone for a user from the database. I have the user and his time zone, thats's no problem.

The problem is the presentation logic. There are DateTime.now methods all over the code, to convert all these methods is a lot of work.

To avoid that I need a global time zone setting where the DateTime knows which time zone it is. Preferably on a generic place.

class business logic 

InitializeCulture() 
 set time zone for user 
end function 

end class

class presentation logic  

sample()
 TimeOfTheCurrentUser = DateTime.now  
end function

end class

If you are looking for best practice for time zone handling in (more or less) enterprise application, I can share the proven one:

1. Store all date and time related information in UTC. Storing it as local time (on server or wherever else) always brings a risk that somebody, somewhere, someday forget to convert them and the results would be less than ideal. Of course it means that dates and times should be instantiated via DateTime.UtcNow or with proper DateTimeKind selected (this refers to parsing as well).

2. Obviously you need to convert time zone before displaying DateTime to end user. And you surely realize that you need to obtain this information from some source (thus the question). That somewhere could be client-side (which would work especially well with thick client and not so well with thin client's JavaScript) but could be just as well the user profile. If your application has user profiles, I would definitely recommend to allow user to select preferred time zone. Other g11n-related settings would be preferred culture for e-mails or preferred language. All of these settings should be detected and preselected (so the user does not have to think or more importantly click too much).

3. To convert DateTime classes to local time in another time zone, you would use TimeZoneInfo class. There are several ways to do that...

If you would implement this method, you may hit the problem with time zone names - they are in server's culture, so you would need to externalize (move to resource file) what TimeZoneInfo's DisplayName shows you and let translators do their jobs.

Also just a quick word what I meant by detect time zone.
On thick client you would do that by simply reading local time zone:

TimeZoneInfo currentTimeZone = TimeZoneInfo.Local;

With JavaScript (thin client) it is not that easy. The only thing you can get is a time zone offset (which could vary depending on date & time) on given date:

var date = new Date();
var offset = date.getTimezoneOffset(); // GMT offset in minutes