104

我通常有一个“拦截器”，在从/向数据库读取/写入数据之前进行 DateTime 转换（从 UTC 到本地时间，以及从本地时间到 UTC），所以我可以DateTime.Now在整个系统中使用（推导和比较）而不用担心关于时区。

关于计算机之间的序列化和移动数据，无需费心，因为日期时间始终是 UTC。

我应该继续以 UTC 格式存储我的日期（SQL 2008 - datetime）还是应该使用DateTimeOffset（SQL 2008 - datetimeoffset）来存储它？

数据库中的 UTC 日期（datetime 类型）已经工作并且知道这么久了，为什么要更改它？有什么优势？

我已经看过这样的文章，但我并不是 100% 相信。有什么想法吗？

4

3 回答 3

140

有一个巨大的区别，您不能单独使用 UTC。

  • 如果你有这样的场景

    • 一台服务器和多个客户端（都在不同的地理时区）
    • 客户使用日期时间信息创建一些数据
    • 客户端将其全部存储在中央服务器上

  • 然后：

    • datetimeoffset 存储客户端的本地时间和UTC 时间的偏移量
    • 所有客户都知道所有数据的 UTC 时间以及信息来源地的本地时间

  • 但：

    • UTC datetime 仅存储 UTC datetime，因此您在数据来源的客户端位置没有有关本地时间的信息
    • 其他客户端不知道日期时间信息来自该地点的当地时间
    • 其他客户端只能从数据库（使用 UTC 时间）计算其本地时间，而不是数据来源的客户端本地时间

简单的例子是机票预订系统......机票应该包含2次： - “起飞”时间（在“出发”城市的时区） - “着陆”时间（在“目的地”城市的时区）

于 2012-02-16T16:18:32.647 回答
25

在所有历史时间（即记录事件发生）中使用 UTC 是绝对正确的。总是可以从 UTC 到本地时间，但并非总是相反。

什么时候使用当地时间？回答这个问题：

如果政府突然决定改变夏令时，您是否希望这些数据随之改变？

如果答案是“是”，则仅存储当地时间。显然，这仅适用于未来的日期，并且通常仅适用于以某种方式影响人们的日期。

为什么要存储时区/偏移量？

首先，如果您想记录执行该操作的用户的偏移量，您最好这样做，即在登录时记录该用户的位置和时区。

其次，如果要转换为显示，则需要有一个包含该时区所有本地时间偏移转换的表，仅知道当前偏移是不够的，因为如果您显示六个月前的日期/时间，偏移将与众不同。

于 2011-03-10T19:00:22.990 回答
21

DATETIMEOFFSET 使您能够在一个字段中存储本地时间和 UTC 时间。

这允许在本地或 UTC 时间进行非常简单和高效的报告，而无需以任何方式处理数据以进行显示。

这是两个最常见的要求 - 本地报告的本地时间和组报告的 UTC 时间。

本地时间存储在 DATETIMEOFFSET 的 DATETIME 部分，与 UTC 的偏移量存储在 OFFSET 部分，因此转换很简单，并且由于不需要知道数据来自的时区，都可以在数据库级别完成.

如果您不需要精确到毫秒的时间，例如只需几分钟或几秒钟，您可以使用 DATETIMEOFFSET(0)。DATETIMEOFFSET 字段将只需要 8 个字节的存储空间 - 与 DATETIME 相同。

因此，使用 DATETIMEOFFSET 而不是 UTC DATETIME 为报告提供了更大的灵活性、效率和简单性。

于 2013-06-08T17:35:00.323 回答