为什么“时区”不确定？

SQL Server 2016 AT TIME ZONE似乎不确定。但是，我无法找到正式说明这一点的文档，也无法找到其背后的理由。

为什么AT TIME ZONE不确定？

显示非确定性的示例

执行中：

CREATE TABLE Test (
    LegacyTimestamp DATETIME,
    Timestamp AS LegacyTimestamp AT TIME ZONE 'Eastern Standard Time' PERSISTED
);

返回以下错误：

Msg 4936, Level 16, State 1, Line 1
Computed column 'Timestamp' in table 'Test' cannot be persisted because the column is non-deterministic.

sql-server sql-server-2016 timezone

— 本·格里博多
source

三个词。夏令时。

— 狗仔队

欢迎来到被称为时间的噩梦。我几乎希望当您存储时间时它是强制性的，并且还存储了哪个时区。我会节省很多头痛药。

— 埃里克·S

刚刚创建了一个Microsoft Connect项目，要求更新文档以反映“ AT TIME ZONE”的不确定性。

— Ben Gribaudo

Answers:

AT TIME ZONE 采用某些逻辑来计算夏令时。DST偏移值不是一成不变的（它们可能会通过Windows Update进行更改），并且包含在Windows注册表的外部，因此该AT TIME ZONE功能不能确定，因为它依赖于外部数据。

同样，这就是为什么sys.time_zone_info是视图而不是静态参考表的原因，需要根据具有最新时区信息的注册表值来计算它。

— LowlyDBA
source

但这不应该参考转换日期来计算吗？如果不是确定性的，那是因为将来夏时制开始的规则可能会像2009

— 。– Random832 '09

@ Random832对！我已经跳过了一些细节，我已经更新为更加清楚。

— LowlyDBA

@ Random832，不仅要考虑过去的日期，还要考虑将来的日期。如果根据今天存在的时间更改规则存储了将来的日期，则如果此刻之间更改规则，则该值将变为无效，

— Dan Guzman

约翰：这是很好的信息，但是重新排列一下以表示不确定性的实际原因仅仅是由于外部依赖于从注册表获取信息的实际原因，这在技术上是否更准确？当然，为什么它必须从那里获取信息而不是硬编码到应用程序代码中（即根本原因），主要是由于DST规则更改的频率以及可以引入新时区的事实，但这真的是次要的，对吧？但是，不管“为什么”，任何外部依赖关系都应使任何函数都不确定。

— 所罗门·鲁兹基

太棒了！仅供参考，我在这里找到了一些非常有趣的信息-en.wikipedia.org/wiki/Tz_database-似乎是少数文件（至少到目前为止我能找到）表明DST并不是唯一的文件之一改变。通过查看C：\ Windows \ Globalization \ Time Zone \ timezones.xml文件可以看出，即使基本偏移量也可以随时间变化，尽管自1970年以来这种变化的频率较低。+1：-）（由于链接中包含不良字符，因此不得不重新发布）

— Solomon Rutzky

我已将“时区”添加到“确定性和非确定性”主题的非确定性列表中，并且在“时区”主题中，我添加了：由于某些信息（例如时区规则）是在SQL Server外部维护的，因此有时会发生变化， AT TIME ZONE函数被分类为不确定的。感谢您提出来。Rick Byham，SQL Server在线丛书。

— 里克·拜厄姆（Rick Byham）
source

这应该是评论而不是答案！

— Kin Shah