3

这似乎应该是一个显而易见的问题，但我在找到一个好的答案时遇到了一些问题。我正在构建一个需要对 UTC 时间敏感的 n 层应用程序。可以更新值并记录时间戳。这包括数据库中的事务，其中更新或插入将影响日期时间列。

为了给出一些上下文，我对我的大多数日期时间列使用带有 DATETIMEOFFSET(2) 的 SQL 2008 R2 +。我正在考虑将时间戳的更新放入存储过程中，这样它们就不需要通过网络传递。随着系统的增长，这将节省带宽，这是一件好事......并且可用于验证共享数据上的数据是否更改（首先获胜）。不利的一面是，如果他们在应用程序实例上遇到较慢的响应时间，则第一个提交事务的人可能不是获胜者。

在这种情况下处理 UTC 时间数据的理想或推荐方法是什么？

  1. 使用 SYSUTCDATETIME() 或 ... 在 SPROC 中设置它
  2. 使用 DateTimeOffset.Now 或 DateTime.UtcNow 在应用程序中设置它

如果以上两个，是否建议在表示层触发它并将其通过服务传递到域层，或者只是在它到达服务后端的域时设置它？

正如你所看到的，这里有很多选择，我倾向于数据库......但在我继续构建这个东西之前，我会很感激任何建议或警告的话。

旁注：我也在跟踪地理空间信息……但这不是一个硬实时系统。用户实时是绰绰有余的。

更新：我将在应用程序中使用 DateTimeOffset。我的研究使我发现，您“可以通过首先在每个日期上调用 ToUniversalTime 来可靠地比较任何两个 DateTime。当（且仅当）其中一个具有“未指定”的 DatTimeKind 时，此策略失败。他失败的可能性是另一个青睐 DateTimeOffset 的原因” - C# 4.0 简而言之，O'Riely 书籍。

4

1 回答 1

3

我投票赞成在过程中设置它（或列的默认值，用于插入）。没有理由通过所有层传递所有这些信息，除非您需要微秒级的精度来区分，例如用户单击按钮的时间与事务在数据库中提交的时间。如果您有一个分布式应用程序，则尤其如此——您是否想依赖所有的 Web/应用程序服务器来同步，而不介意客户端/服务器应用程序的最终用户工作站？您可能在不同的数据中心拥有服务器，它们都具有不同的时区，有些遵守 DST，有些则没有，等等。DateTime.UtcNow应该消除大部分差异，但我仍然会无缘无故地返回传递所有这些数据。数据库知道现在是什么时间；让它为您存储值，并将所有逻辑排除在应用程序之外。

（此外，如果您要存储 UTC 时间，您真的需要DATETIMEOFFSET吗？如果是这样，那么您仍然需要一些方法让该过程知道该信息来自哪个时区。如果没有，那么您可能应该SMALLDATETIME/DATETIME/DATETIME2根据所需的准确性使用。 )

于 2013-03-27T23:53:51.027 回答