这似乎应该是一个明显的问题，但我有一些问题找到一个好的答案。我正在构建一个n层应用程序，需要是UTC时间敏感。值可以被更新，当它们是时间戳时被记录。这包括数据库中更新或插入将影响datetime列的事务。
给出一些上下文，我使用SQL 2008 R2 +与DATETIMEOFFSET(2)大多数我的日期时间列。我正在考虑将时间戳的更新放到存储过程中，这样它们就不需要通过网络传递了。随着系统的增长，这将节省带宽，这是一件好事……并且可以用来验证共享数据上的数据是否发生了变化(先赢)。不利的一面是，如果第一个提交事务的人在他们的应用程序实例上遇到较慢的响应时间，那么他们可能不是赢家。
在这种情况下处理UTC时间数据的理想或推荐方法是什么?
- 在SPROC中使用SYSUTCDATETIME()或…
- 在应用程序中用DateTimeOffset设置它。Now或DateTime。UtcNow
如果上面有两个，是建议在表示层触发它并通过服务将其传递到域层，还是只在它到达服务后端的域时设置它?
正如你所看到的，这里有很多选择，我倾向于数据库…但在我继续建造这个东西之前，我希望得到任何建议或警告的话。
旁注:我也在跟踪地理空间信息…但这不是一个硬实时系统。用户实时性绰绰有余。UPDATE:我将在应用程序中使用DateTimeOffset。我的研究让我发现，可以通过首先调用tuniveraltime来可靠地比较任何两个DateTimes。当(且仅当)其中一个的DatTimeKind为"未指定"时，此策略失败。"DateTimeOffset"——c# 4.0 In a Nutshell, O'Riely books。
我赞成在过程中设置它(或者为insert设置列的默认值)。没有理由通过所有层传递所有这些信息，除非你需要微秒精度来区分，例如，当用户单击按钮时与在数据库中提交事务时。如果你有一个分布式应用程序，这一点尤其正确——你想要依赖所有的web/应用服务器同步吗?不要担心客户端/服务器应用程序的终端用户工作站。您可能在不同的数据中心拥有不同的服务器，它们都具有不同的时区，有些遵循夏令时，有些不遵循夏令时，等等。DateTime.UtcNow应该消除大部分这些差异，但我仍然会回到毫无理由地传递所有数据。数据库知道时间;让它为您存储值，并将所有的逻辑都排除在应用程序之外。
(另外，如果您存储的是UTC时间，您真的需要DATETIMEOFFSET吗?如果是这样，那么您仍然需要某种方法让过程知道此信息来自哪个时区。如果没有，那么你可能应该只使用SMALLDATETIME/DATETIME/DATETIME2取决于所需的精度)