SQL Server DateTime 参数“舍入”警告

与其说是问题，不如说是警告：

今天早上我们解决了一个非常令人费解的错误。我们有各种报告，允许用户输入他们想要运行的日期范围。假设是，如果您要求提供 2010 年 8 月 1 日至 2010 年 8 月 10 日的报告，您的意思是include2010 年 8 月 10 日，因此报告的结束日期不是 8 月 10 日，而是在那之后。

它不可能是 2010 年 8 月 11 日，因为其中一些报告汇总了一天中发生的所有情况，并按当天午夜进行分组，因此每日汇总将包括额外的一天 - 这不是我们想要的。

为了避免在接近一天结束时遗漏任何项目的可能性，我们将结束日期计算为比明天少“一个刻度”：

public static DateTime EndOfDay(DateTime day)
{
    return day.Date.AddDays(1).AddTicks(-1);
}

在内部，这最终类似于 8/10/2010 12:59:59.9999PM

那么，当您将此 DateTime 传递给 SQL Server 中的 DATETIME 参数时，它会将值向上舍入为 8/11/2010 00:00:00！由于我们的查询使用

DateField BETWEEN @FromDate AND @ToDate

代替

DateField >= @FromDate AND DateField < @ToDate

我们看到 2010 年 8 月 1 日至 2010 年 8 月 10 日的报告包含 2010 年 8 月 11 日的项目。

我们发现真正问题的唯一方法是通过字符串来回传递日期。 DateTime.ToString() 也会进行舍入，因此我们最终得到 SQL Server 满意的 8/1/2010 12:59:59PM。

现在我们的“一天结束”方法如下所示：

public static DateTime EndOfDay(DateTime day)
{
    // Cant' subtract anything smaller (like a tick) because SQL Server rounds UP! Nice, eh?
    return day.Date.AddDays(1).AddSeconds(-1);
}

抱歉，这不是一个问题 - 只是认为有人可能会发现它有用。

这是因为 DATETIME 数据类型的准确性，其精度为 (quote http://msdn.microsoft.com/en-us/library/ms187819(v=SQL.100).aspx):

四舍五入到 0.000、0.003 的增量， 或 0.007 秒

所以，是的，在某些情况下您必须小心（例如，23:59:59.999 将四舍五入到第二天的 00:00，23:59:59.998 将四舍五入到 23:59:59.997）

SELECT CAST('2010-08-27T23:59:59.997' AS DATETIME)
SELECT CAST('2010-08-27T23:59:59.998' AS DATETIME)
SELECT CAST('2010-08-27T23:59:59.999' AS DATETIME)

从 SQL Server 2008 开始，有一个新的日期时间2 http://msdn.microsoft.com/en-us/library/bb677335(v=SQL.100).aspx数据类型的精度更高，低至 100 纳秒。

当我对包含时间元素的 DATETIME 字段进行查询时，由于这个原因，我不使用 BETWEEN 。

例如我更喜欢

WHERE DateField >= '2010-08-27' AND DateField < '2010-08-28'

代替：

WHERE DateField BETWEEN '2010-08-27' AND '2010-08-27T23:59:59.997'