我认为DateTimeOffset唯一的缺点是微软“忘记”(故意)在他们的XmlSerializer类中支持它。但是它已经被添加到XmlConvert实用程序类中。

XmlConvert。ToDateTimeOffset

XmlConvert。ToString

我建议继续使用DateTimeOffset和TimeZoneInfo，因为它们都有好处，只是在创建将或可能序列化到XML或从XML序列化的实体时要小心(那时都是业务对象)。

从微软:

DateTimeOffset值的这些用法比DateTime值的用法更常见。因此，应该将DateTimeOffset视为应用程序开发的默认日期和时间类型。

来源:“选择DateTime, DateTimeOffset, TimeSpan和TimeZoneInfo”，MSDN

当我们的应用程序处理特定的时间点时(例如，当一个记录被创建/更新时)，我们几乎所有的事情都使用DateTimeOffset。顺便说一句，我们在SQL Server 2008中也使用了DATETIMEOFFSET。

我认为，当您只想处理日期、时间或在一般意义上处理这两种情况时，DateTime非常有用。例如，如果您有一个闹钟，希望每天早上7点响，您可以使用未指定的DateTimeKind将其存储在DateTime中，因为您希望它在早上7点响，而不考虑夏令时。但是，如果希望表示告警发生的历史，则可以使用DateTimeOffset。

在混合使用DateTimeOffset和DateTime时要谨慎，特别是在类型之间进行分配和比较时。同样，只比较DateTimeKind相同的DateTime实例，因为DateTime在比较时忽略了时区偏移。

在一些地方，DateTimeOffset是有意义的。一种是处理重复事件和夏时制时。假设我想设置一个闹钟，让它每天早上9点响。如果我使用“存储为UTC，显示为本地时间”规则，那么当夏令时生效时，闹钟将在不同的时间响起。

可能还有其他的例子，但上面的例子实际上是我过去遇到的一个(这是在将DateTimeOffset添加到BCL之前-我当时的解决方案是显式地将时间存储在本地时区，并将时区信息保存在旁边:基本上是DateTimeOffset内部做的事情)。

日期时间.现在 免费 03 12月 21 18：40：11

DateTimeOffset.Now 免费 03 12月 21 18：40：11 +02：00

因此，DateTimeOffset存储有关时间如何与UTC(基本上是时区)相关的信息。

一个主要的区别是DateTimeOffset可以与TimeZoneInfo一起使用，以转换为当前时区以外的本地时间。

这对于由不同时区的用户访问的服务器应用程序(例如ASP.NET)非常有用。

微软的这段代码解释了一切:

// 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