TimeZones和DST的MS SQL Server故事（我们需要重新发明轮子吗？）

Question

我正在寻找有关TSQL和SQL作业调度时间本地化的建议和个人经验（我们正在使用SQL Server 2012）。

我遇到过需要在MS SQL Server中支持时区和DST支持的情况：

• 尝试在不同时区存储自动计算的日期列，以便能够对此列进行集群索引。
• 能够以UTC时间更新包含datetime2字段的现有表格，以实现以前的目标（例如PST日期的索引表;没有时间部分）
• 尝试安排在不同时区以特定时间运行的sql作业（例如，创建仅包含当前PST日数据的物化视图）。

我在网上搜索并发现了这些可能性：

• A 存储表格，其中包含时区偏移+ DST信息，并使用TSQ计算正确的本地化时间（=重新启动需要使用时区信息维护表格的轮子）
• B 在客户端代码中完全执行本地化并将结果存储在DB中。此选项需要用于更新现有数据的自定义丢弃应用程序，以及替换sql作业功能的自定义计划任务应用程序。
• C 使用CLR存储过程。我还没有更深入地研究这个选项。

还有其他选择吗？ 是否有任何强大的利弊可以排除这种选择或其他选择？

Answer 1

不幸的是，你的可能性“A”和“B”是目前唯一可行的两种方法。

选项“A”的缺点是维护成本，我还没有看到一些干净地将有效时区数据库（例如the IANA database）解析为具有在这些表上运行的函数的SQL表的东西干净。这应该是可行的，我还没有看到它。 （请注意，它确实存在for MYSQL，Oracle和Postgres内置了它们，但我知道的MS SQL Server没有。）

选项“B”是通常的建议，但是您会遇到一些无法实现的用例，例如您提到的那些用例。更常见的用例是为特定时区发出“每日报告”。必须首先将UTC日期时间转换为特定时区时，按日期分组是不可实现的。此外，人们可能希望从SSRS或其他报告工具运行这些。

选项“C”听起来很有希望，但是存在一个问题：TimeZoneInfo类无法在SQLCLR中运行，除非您启用“不安全”模式，这会产生安全性和稳定性风险，这对于生产来说是不可取的环境。您可以阅读更多here。

我正在研究一个更好的解决方案，即修改Noda Time以便从“安全”模式SQLCLR环境中使用。这是路线图，初步测试看起来很有希望。这需要你使用IANA TZDB time zones，这无论如何都可能是一个好主意。完成后，您将拥有一些简单的用户定义函数来执行时区转换，这些转换依赖于Noda Time程序集的代码和数据。我会在它准备好后更新这篇文章，但我还没有ETA。

<强>更新 经过大量测试后，我认为构建基于SQL的解决方案会更好，类似于选项A中描述的内容。您现在可以使用我的SQL Server Time Zone Support项目，该项目导入IANA时区数据（通过Noda时间）直接进入SQL-Server表。然后它将该信息绑定到您可以调用以便轻松转换的函数。它可靠且可维护，适用于所有SQL Server环境，2008 R2及更高版本，包括Azure SQL DB。