ISO 周与 SQL Server 周

Question

好的，所以我有一份报告进行了本周与上周的比较，我们的客户注意到他们的数据是“时髦的”。经过进一步调查，我们发现它没有按照 ISO 标准正确运行数周。我将此脚本作为测试用例运行。

SET DATEFIRST 1
SELECT DATEPART(WEEK, '3/26/13')
    , DATEPART(WEEK, '3/27/12')
    , DATEPART(WEEK, '3/20/12')
    , DATEPART(WEEK, '1/2/12')
SELECT DATEPART(ISO_WEEK, '3/26/13')
    , DATEPART(ISO_WEEK, '3/27/12')
    , DATEPART(ISO_WEEK, '3/20/12')
    , DATEPART(ISO_WEEK, '1/2/12')

运行时我得到了这些结果。

我认为这很奇怪，所以我做了更多的挖掘，发现 SQL Server 将 1 月 1 日计算为一年的第一周，而 ISO 将 1 月的第一个星期日计算为一年的第一周。

这个问题最终有两个方面。问题1 这是为什么？问题 2 有什么方法可以改变这一点，这样我就不必修改我的所有代码以ISO_Week在任何地方使用？

Answer 1

回到 SQL Server 首次实现WEEK日期/部分时，他们必须做出选择。我不认为有太多的意识，除了符合当时最常见的标准 - 请记住，这是在符合标准不是首要任务的时候（否则我们不会有像timestamp,IDENTITY和TOP)。他们后来补充说ISO_WEEK（我相信是 2008 年），因为在此期间的解决方法是编写自己的、缓慢的、蹩脚的标量 UDF - 事实上，他们甚至创建了一个非常糟糕的 UDF 并将其放入官方文档中（此后已被删除）据我所知）。

我不知道有什么方法可以DATEPART(WEEK假装它DATEPART(ISO_WEEK- 我认为您将不得不更改代码（如果您使用的是源代码管理，这应该不是很困难 - 您在多少地方执行此计算？有你想过在某个地方计算它，这样你的代码就不必被它弄得一团糟？既然你现在正在改变代码，这可能是时候考虑这个了......）。

如果你真的想知道为什么？我认为你必须抓住一些最初的开发人员来确定他们为什么选择他们所做的默认。再说一次，我认为这不是真正的“F 标准！” 选择，而是“什么标准？”

这里有一些可能有用的信息：

/sf/ask/24421631/

http://blogs.lessthandot.com/index.php/DataMgmt/DataDesign/iso-week-in-sql-server