views:

72

answers:

4

Our current app stores all dates via the server's datetime. I'm thinking we need to update all datetime values in the database over to UTC time.

Now for displaying these dates back to the user, I know .Net 3.5 has datatypes that are specific to date time offsets. But does anyone see anything wrong with setting an application variable to represent the desired time zone for the site, and then do a dateadd with that offset to display times back to the user? For instance the Eastern Time zone would have a value of "-5".

A: 

Have a look at Coding Best Practices using DateTime in the .NET Framework. It isn't a tough read and you'll thank yourself for implementing them this way down the road - for example, you won't have to deal with daylight savings changes if you use .NET's provided timezone handling, for example.

Mike Atlas
+1  A: 

Sounds like to you want to re-invent the wheel. If the application is a web app or geographically distributed, you need to know the time zone of the users. Knowing the server's correct time may not be helpful to them.

See this question for a code example:

http://stackoverflow.com/questions/893689/how-to-render-local-time-given-utc-datetime-values-in-asp-net-without-using-javas

cdonner
But my question is do I need to convert my current db values (which are currently set to the local time of the server) to be UTC instead?
I misunderstood - so you are asking if you can allow an offset to your datetime values? Sure,technically you can do that, but I would not, for two reasons:- if your application adds an offset, only your application (and you) will know how to interpret the data in the database- it is easy to fix your existing data
cdonner
So should my current datetime values be converted over to UTCTime or to something like Sql 2008's DateTimeOffset, which stores the offset along with the date?
Wouldn't that require two steps to display a datetime localized to a user's time zone (implicit or explicit)? First you'd have to convert to UTC, then to the user's time zone? I don't see any advantage from doing this, but then I don't have the full business context.
cdonner
A: 

Well, as long as you handle daylight savings "properly". Other than that, if your DB has anything to do with web, records should definitively store UTC. UTC does not "jump" on daylight savings time, so there is no trouble with sorting records entered during time change and datediff calculus is always ok.

Damir Sudarevic
A: 

In the latest version of .NET you get the TimeZoneInfo class that helps with converting dates.

You store the dates in GMT, also store the user's time zone, and then convert the dates each time you need to display them. The hard part is dealing with daylight savings time. The TimeZoneInfo class should help with this. Before that class was available you had to do it all yourself, storing tables of data on time zones and the date ranges of daylight savings time in each time zone.

Eric Z Beard