Every website worth anything has a database of some kind. A lot of programmers do not like to think too much about this part of the application. I am an architect and part of that is dealing with everything as a whole and analyze if it fits with a solution. We will be focusing mainly on the storage in this entry and more specifically the storage of date/time values.
Date/time is tracked everywhere within application and is usually tracked relatively. Most date/times are recorded to your data storage as DateTime.Now(.Net) or GetDate()(Sql Server). This is easy and as far as you know there is nothing wrong with this. In fact you may even think this is great because you are capturing when someone created or modified something for auditing or a scheduling a task that has to be run. Tracking for auditing is great.
The problem with retrieving a value from DateTime.Now or GetDate() is that they are relative time values. Once you saved that data to your data storage like Sql Server is when you can start running into problems. You see storing relative server date/time is an extremely biased recording event. You are no longer flexible in your hosting environment and it may prevent you from moving to a cloud environment or even changes within your hosting provider. Employees outside your current time zone may also be misguided as to what is actually happening in the system because they only see a date they may think it is relative to where they are.
The way to properly record date/time data should be through storing UTC(absolute) time. Most all programming languages have the ability retrieve absolute time(UTC) DateTime.UtcNow(.Net) or GetUTCDate()(Sql Server). I also like to add an indicator in my column name in my db that the date/time is UTC. For example a column name may be “CreatedDateUTC” so that way I know how to display the data stored for that column.
Now that you are recording the absolute time you must now display the correct date/time to the end user. Here is what you should do:
- Using javascript request the end users timezone
- Save the end users timezone to a cookie
- Use the timezone cookie to get the timezone offset in your server side code
- Have a server side function that is accessible throughout your whole application like an extension method that converts the given date/time for the end user to their time using the timezone offset
- Always record UTC date/time to your data storage
Doing these few steps to ensure there will be less confusion within your application and allow users to view data relevant to where they are working from . You will also be able to be more portable and move your websites or databases to the cloud or hosting environments outside of your time zone.
Josh T. Let me know if you have any questions and I will more than happy to help out. Thanks for reading. 
emt training on 
on 
Curt on 
Medicine Ball Exercises on 
Adam J Wolf on 
Facebook
RSS
Sound advise, even if you are storing dates for a business in only one timezone. Many hours are spent fixing this when the inevitable expanding user base reaches another timezone. Do it right the first time. Great post.
Adam J Wolf
It’s posts like this that keep me coming back and checking this site regularly, thanks for the info!
Great post! I learned this lesson the hard way many years ago when I built a web application for tracking power plant production for a big energy company. The manager came to me near the end of the project and told me I had to make it work for another plant … in another time zone! Worse, the new plant was in a region that didn’t observe daylight savings time, while most of the users were in a region that did, so I couldn’t even use a constant offset to do the conversion. Luckily there were only a handful of date/time columns, and since then, UTC has been my standard.
This helped me alot in my college assignement. Thanks for your information.