Derick Rethans has a new post to his blog that helps to demystify some of the confusion around storing dates correctly in your application's database. He mentions a suggested method of using the UTC time and offset together, but talks about why this isn't the best alternative.

After my talk during ConFoo on Advanced Date/Time Handling I received a question about whether the UTC-offset, together with the date/time in years, months, days, hours, minutes and seconds, was enough for storing a date/time in a database and still being able to do calculations with this. The answer to this question was no, but it lead to an even more interesting discussion about what would be enough to store an accurate date/time in a database.

He mentions the main issue with the UTC-offset method - time changes like Daylight Saving throwing a wrench into the works and how adding/subtracting hours doesn't always work as expected. His suggestion is to store the actual DateTime object information representing the location in question, the timezone identifier and the date/time information as strings. Then, when you need to calculate the date information on the other side, you can recreate it with a DateTime and DateTimeZone objects.