时间戳vs时间戳

DateTimeOffset是瞬时时间的表示（也称为绝对时间）。我的意思是对每个人都通用的时间时刻（不包括闰秒，或时间膨胀的相对论效应）。另一种表示瞬时时间的方法是使用DateTime，其中.Kind是DateTimeKind.Utc。

这与日历时间（也称为民事时间）不同，后者是某人日历上的位置，全球有许多不同的日历。我们称之为日历时区。日历时间由DateTime表示，其中.Kind是DateTimeKind.Unspecified或DateTimeKind.Local。.Local仅在您隐含了解使用结果的计算机定位的情况下才有意义（例如，用户的工作站）

那么，为什么DateTimeOffset而不是UTCDateTime呢？这都是关于视角的。让我们打个比方——我们假装是摄影师。

想象一下，你正站在日历时间线上，用相机对着面前即时时间线上的一个人。你根据自己所在时区的规则排列相机——时区会因为夏令时或时区法律定义的其他变化而定期变化。（你的手不稳，所以相机会摇晃。）

站在照片中的人会看到你的相机来自的角度。如果其他人正在拍照，他们可能是从不同的角度拍摄的。这就是DateTimeOffset的Offset部分所代表的。

因此，如果您将相机标记为“东部时间”，有时您指向-5，有时您指向-4。世界各地都有相机，标记不同的事物，并且从不同的角度指向相同的瞬时时间线。其中一些彼此相邻（或在顶部），因此仅知道偏移量不足以确定时间与哪个时区相关。

那么UTC呢？嗯，它是唯一能保证手部稳定的相机。它在三脚架上，牢牢地固定在地上。它哪儿也去不了。我们称它的视角为零偏移。

那么，这个类比告诉我们什么呢？它提供了一些直观的指导——

• 如果您要表示特定地点的时间，请使用DateTime表示日历时间。请确保您永远不会将一个日历与另一个日历混淆。Unspecified应该是您的假设。Local仅在来自DateTime.Now时有用。例如，我可能会获取DateTime.Now并将其保存在数据库中-但当我检索它时，我必须假设它是Unspecified。我不能依赖我的本地日历与最初使用的日历相同。

• 如果您必须始终确定时刻，请确保您表示的是瞬时时间。使用DateTimeOffset强制执行它，或按照惯例使用UTCDateTime。

• 如果您需要跟踪瞬时时间，但您也想知道“用户认为它在本地日历上的时间是什么时间？”-那么您必须使用DateTimeOffset。这对于计时系统非常重要，例如，无论是技术还是法律问题。

• 如果您需要修改以前记录的DateTimeOffset-您没有足够的信息仅在偏移量来确保新的偏移量仍然与用户相关。您必须还存储一个时区标识符（想想-我需要相机的名称，这样即使位置发生了变化，我也可以拍摄新照片）。

  还应该指出的是，野田时间有一个名为ZonedDateTime的表示，而. Net基类库没有类似的东西。您需要同时存储DateTimeOffset和TimeZoneInfo.Id值。

• 有时，你会想要表示“正在查看它的人”本地的日历时间。例如，在定义今天的含义时。今天总是午夜到午夜，但这些代表了瞬时时间轴上几乎无限数量的重叠范围。（在实践中，我们有有限数量的时区，但你可以将偏移量表达到刻度）所以在这些情况下，确保你理解如何将“谁在问？”问题限制在一个时区，或者处理如何将它们转换回适当的瞬时时间。

这里有一些关于DateTimeOffset的其他小东西支持这个类比，以及一些保持直截了当的提示：

• 如果比较两个DateTimeOffset值，在比较之前，它们首先被归一化为零偏移。换句话说，2012-01-01T00:00:00+00:00和2012-01-01T02:00:00+02:00指的是相同的瞬时矩，因此是等价的。

• 如果您正在进行任何单元测试并且需要确定偏移量，请分别测试DateTimeOffset值和.Offset属性。

• . net框架内置了一个单向隐式转换，可以让你将DateTime传递给任何DateTimeOffset参数或变量。这样做的时候，.Kind很重要。如果你传递UTC类型，它将以零偏移量进位，但如果你传递.Local或.Unspecified，它将假设是本地。该框架基本上是说，“嗯，你让我将日历时间转换为瞬时时间，但我不知道这是从哪里来的，所以我只使用本地日历。”如果您在具有不同时区的计算机上加载未指定的DateTime，这是一个巨大的陷阱。（IMHO-这应该抛出异常-但它没有。）

无耻插头：

很多人和我分享，他们发现这个类比非常有价值，所以我把它包括在我的Pluralsight课程日期和时间基础中。你会在第二个模块“上下文事项”中找到相机类比的逐步走查，在标题为“日历时间与瞬时时间”的剪辑中。