这似乎应该是一个显而易见的问题,但我遇到了一些问题,找到了一个好的答案.我正在构建一个需要对UTC时间敏感的n层应用程序.可以更新值以及何时记录时间戳.这包括数据库中的事务,其中更新或插入将影响datetime列.
为了给出一些上下文,我在大多数日期时间列中使用带有DATETIMEOFFSET(2)的sql 2008 R2.我正在考虑将时间戳的更新放入存储过程,以便它们不需要通过网络传递.这将在系统增长时节省带宽,这是一件好事……并且可用于验证数据是否在共享数据上发生变化(首次获胜).不利的一面是,提交事务的第一个可能不是那个在他们的应用程序实例上遇到较慢响应时间而获胜的人.
在此上下文中处理UTC时间数据的理想或推荐方法是什么？
>使用SYSUTCDATETIME()或在…中将其设置在SPROC中
>使用DateTimeOffset.Now或DateTime.UtcNow在应用程序中设置它
如果上面有两个,是否建议在表示层触发它并将其通过服务传递给域层,或者只是在它到达服务后端的域时设置它？
正如你所看到的,这里有很多选择,我倾向于数据库…但在继续构建这个东西之前,我会感激任何建议或警告的话.
旁注：我也在跟踪地理空间信息……但这不是一个硬实时系统.用户实时绰绰有余.
更新：我将在应用程序中使用DateTimeOffset.我的研究让我发现你“可以通过首先在每个上调用ToUniversalTime来可靠地比较任何拖曳日期时间.如果(并且仅当)其中一个具有”未指定“的DatTimeKind,则该策略失败.这种失败的可能性是另一个赞成DateTimeOffset的原因“ – C#4.0在果壳中,O’Riely书籍.
解决方法
我投票在程序中设置它(或列的默认值,插入).没有理由将所有这些信息传递到所有图层,除非您需要微秒精度来区分,例如当用户单击按钮时,与在数据库中提交事务时相比.如果您拥有分布式应用程序,尤其如此 – 您是否希望依赖所有Web /应用程序服务器同步,更不用关心客户端/服务器应用程序的最终用户工作站了？您可能有不同数据中心的服务器,所有服务器都有不同的时区,有些服务器正在观察DST,有些则没有,等等.DateTime.UtcNow应该消除大部分差异,但我仍然会回过头来无缘无故地传递所有数据.数据库知道它的时间;让它为你存储价值并将所有逻辑保留在应用程序之外.
(另外如果你正在存储UTC时间,你真的需要DATETIMEOFFSET吗？如果是这样,那么你仍然需要一些方法让程序知道这个信息来自哪个时区.如果没有,那么你应该只使用SMALLDATETIME / DATETIME / DATETIME2取决于所需的准确度.)
