应用错误收集

在Windows Server 2008 R2上运行SQL Server 2008 R2。

我们最近发现SQL Server getdate（）函数似乎没有像我期望的那样在当地时间凌晨2:00切换到/从夏令时开始。服务器的时区设置为“（UTC-06：00）中部时间（美国和加拿大）”，并选中“自动调整夏令时的时钟”复选框。

作为一个例子，我们有一个包含多个列的表，其中一个列的类型为datetime，默认约束为getdate（）。我们有一个将记录插入该表的进程，允许SQL为该列提供默认值。这是我们2017年3月12日早上（中部时间）早些时候运行的结果：

2017-03-12 01：59：55.797
2017-03-12 01：59：57.707
2017-03-12 01：59：58.243
2017-03-12 02：00：01.570
2017-03-12 02：00：01.640
2017-03-12 02：00：02.990
... 在02:00:03和02:01:16之间省略类似的结果
2017-03-12 02：01：16.317
2017-03-12 02：01：17.393
2017-03-12 02：01：20.577
2017-03-12 03：01：22.720
2017-03-12 03：01：24.853
2017-03-12 03：01：25.397

上面的结果按标识列排序，因此我假设按列出的顺序插入。根据美国中部时间的夏令时规则，粗体中的时间无效。最后，在大约一分钟和21秒之后，系统发现它需要切换到DST，因此所有后续记录都是正确的。当切换回11月的标准时间时似乎存在类似的问题 - getdate（）继续在DST返回时间超过第一次出现的凌晨2:00，然后跳回一小时到标准时间。

也许这只是底层Windows API GetLocalTime函数的行为方式？无论如何，我的问题是：

这是一种已知或预期的行为吗？
如果是这样，原因和原因是什么？
sysdatetimeoffset（）函数是否具有相似的行为，即它是否返回了如上所示的相同日期和时间部分，尽管希望具有自我一致的偏移量？

FWIW，我们正在将此和其他类似的日期时间列转换为类型datetimeoffset，并计划使用sysdatetimeoffset（）SQL函数来填充它。我们在开发脚本以更新现有数据的偏移量时发现了这种意外行为。

提前感谢您提供与此主题相关的任何信息！

SQL Server getdate（）切换到/从DST切换比预期更快一分钟

0 个答案: