We were always taught, whenever storing or comparing dates always store them as UTC. That’s how I remember it at least. But that is not actually the correct answer. According to the detailed Coding Best Practices Using DateTime in the .NET Framework the rules state “a developer is responsible for keeping track of time-zone information associated with a DateTime value via some external mechanism”. Which leads to the recommended Storage Strategies Best Practice #1:

When coding, store the time-zone information associated with a DateTime type in an adjunct variable.

I don’t think I have ever seen this actually done. But no worries, since .NET 3.5 and SQL Server 2008 there is new type to use. Today I was just introduced to DateTimeOffset. This solves the issues of storage and calculations ensuring that the time zone offset is always stored with the date.

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

The code sample on the documentation page I think shows the difference and usefulness quite well.

using System;

public class DateArithmetic
{
   public static void Main()
   {
      DateTime date1, date2;
      DateTimeOffset dateOffset1, dateOffset2;
      TimeSpan difference;

      // Find difference between Date.Now and Date.UtcNow
      date1 = DateTime.Now;
      date2 = DateTime.UtcNow;
      difference = date1 - date2;
      Console.WriteLine("{0} - {1} = {2}", date1, date2, difference);

      // Find difference between Now and UtcNow using DateTimeOffset
      dateOffset1 = DateTimeOffset.Now;
      dateOffset2 = DateTimeOffset.UtcNow;
      difference = dateOffset1 - dateOffset2;
      Console.WriteLine("{0} - {1} = {2}", 
                        dateOffset1, dateOffset2, difference);
      // If run in the Pacific Standard time zone on 4/2/2007, the example 
      // displays the following output to the console: 
      //    4/2/2007 7:23:57 PM - 4/3/2007 2:23:57 AM = -07:00:00 
      //    4/2/2007 7:23:57 PM -07:00 - 4/3/2007 2:23:57 AM +00:00 = 00:00:00                        
   }
}

When would you prefer DateTime over DateTimeOffset? Introduced here by the BCL team and it is detailed when you may want to use the DateTime over the DateTimeOffset. Summarized I would say it is when you are doing interop with OLE or when you don’t care about time only date, like birthdays.

DateTimeOffset is the new preferred type to use for the most common date time scenarios.

Shortcomings due to the loss of time zone information and only using the offset is the main issue. If you are really serious about dates and time and are heavily using them, you may consider Noda Time started by Jon Skeet. My only issue with using DateTimeOffset virtually all the time in place of DateTime is that I have only found out about this years later.