上文中我们介绍了DateTime的存储格式，以及如何使用DateTime；本文主要讲述DateTime类型四舍五入的问题。
2. DateTime类型四舍五入问题(rounding issues)
DateTime 与 String 之间的转换并总是精确的。例如，“20060923 03：23：47：001” 转换为DateTime类型时，此项将会转换为离百分之三秒最近的时间。那将会转换为“20060923 03：23：47.000”。为什么转换结果是这样呢？ 是由于数据总是被转换为 离 3/1000秒为计算单位的最近的时间。（那我们是否可以这样理解这次转换呢？其实，这次转换涉及到的结果可以是 .000 和 .003 ，依据离3/1000秒最近的原则，.001 到.000为1毫秒 .001 到.003 是2毫秒，所以结果是.000）.上述的字符串如果转换为Smalldatetime类型时，结果将会是"20060923 03:24:00". 转换为SmallDateTime时,总是将结果转换为离 分为计算单位最近的时间。（可以这样理解，03：23：47 转换为SmallDateTime时，可以转换为 03:23:00 和 03：24：00 由这两个结果可以知道，转换字符离03:24:00 只有13秒，所以转换为 03：24：00.）那如果转换字符分别为 “03：23：30 ” 和“03：23：29”时，转换结果是什么呢？结果为“03：24：00” 和“03：23：00”。
同样，当String 类型转换为DateTime时，结果也是不精确的。String类型的值会被转换为最接近的DateTime类型值。而不会向Decimal类型的值向INT类型的转换，只是简单的将后续的小数部分去掉，如10.99转换结果为10。DateTim数据的毫秒部分总是遵循以下的格式，[0-9][0-9][037]。例如，毫秒部分的值为994时，在转换为DateTime类型时，最终的结果将会是997. 999将会转换为下一秒的000。因此，对于如下的语句而言，这就不是一个很好的过滤语句：
Where Dt between '20060211 00：00：00.000' and '20060211 23:59:59.999' .为什么呢？通过以上分析可知，'20060211 23：59：59.999' 将会转换为'20060212 00:00:00.000'。 因此根据上述条件，最终的结果中将会包含 '20060212 00:00:00.000' 的数据。为了改进上面的内容，我们可以将上边界的值改为'20060211 23:59:59.997'。这样就不会包含 '20060212 00:00:00.000' 的数据了。更好的条件使用方法，如下所示：
Where Dt >= '20060211 00:00:00.000' and Dt<'20060212 00:00:00.000' .这种写法无论DateTime类型还是SmallDateTime类型，都能够正常使用。
一些程序员在使用上面的 Dt >= '20060211 00:00:00.000' and Dt<'20060212 00:00:00.000' 时，喜欢去掉时间部分，写成如下的形式：
Dt >= '20060211' and Dt<'20060212' 在这种形式下，SQL Server 将会将字符形式转换为指定日期的午夜时间。即 '20060211' 转换为 20060211 00：00：00.000.
上面的过滤条件是 Search Argument（SARG），这就意味着查询优化器会考虑使用索引的查询操作提高性能。但是有些人会写成如下的形式，使用SQL Server函数将日期部分取出来，再进行比较，如下：
Where Convert（Varchar(8),dt,112)='20060211' 这种写法不是SARG形式，数据库不会使用索引查询，因此，应当避免此种写法。
原文链接：http://www.cnblogs.com/fisher3/archive/2011/03/31/1998179.html
