接受的答案很好，只需知道，如果您向前端发送DateTime2，它将四舍五入到正常的DateTime等效值。

这给我带来了一个问题，因为在我的解决方案中，我必须在重新提交时将发送的内容与数据库中的内容进行比较，而我的简单比较“==”不允许舍入。所以必须添加它。

Select ValidUntil + 1
from Documents

上面的SQL不适用于DateTime2字段。它返回错误“操作数类型冲突：datetime2与int不兼容”

添加1以获得第二天，这是开发人员多年来一直在使用日期的做法。现在微软有了一个超级新的datetime2字段，无法处理这个简单的功能。

“让我们使用比旧型号更糟糕的新型号”，我不这么认为！

使用非US DATEFORMAT设置时，将日期字符串解释为datetime和datetime2也可能不同。例如。

set dateformat dmy
declare @d datetime, @d2 datetime2
select @d = '2013-06-05', @d2 = '2013-06-05'
select @d, @d2

对于datetime，返回2013-05-06（即5月6日），对于datetime2，返回2013-06-05（即6月5日）。然而，当dateformat设置为mdy时，@d和@d2都返回2013-06-05。

日期时间行为似乎与MSDN的SETDATEFORMAT文档不一致，后者指出：某些字符串格式（例如ISO8601）的解释与DATEFORMAT设置无关。显然不是真的！

直到我被这个问题困扰，我一直认为yyyy-mm-dd日期会被正确处理，不管语言/语言环境设置如何。

如果您是Access开发人员，试图将Now（）写入相关字段，则DateTime2会造成严重破坏。刚刚执行了Access->SQL 2008 R2迁移，它将所有日期时间字段作为DateTime2放入。当值爆炸时，用Now（）追加一条记录。2012年1月1日下午2:53:04没事，但2012年10月1日凌晨2:53:44没有。

一旦性格改变了。希望它能帮助到某人。

老问题。。。但我想补充一些这里没有人说过的话。。。（注：这是我自己的观察结果，所以不要要求任何参考）

在筛选条件中使用Datetime2更快。

TLDR：

在SQL 2016中，我有一个包含十万行和日期时间列ENTRY_TIME的表，因为它需要存储精确到秒的时间。当我使用where子句作为：

WHERE ENTRY_TIME >= '2017-01-01 00:00:00' AND ENTRY_TIME < '2018-01-01 00:00:00'

最初，当有数百行时，查询很好，但当行数增加时，查询开始出现以下错误：

Execution Timeout Expired. The timeout period elapsed prior
to completion of the operation or the server is not responding.

我删除了where子句，出乎意料的是，查询在1秒内运行，尽管现在所有日期的所有行都已提取。我用where子句运行内部查询，用了85秒，没有where子句用了0.01秒。

我在这里遇到了许多关于日期时间过滤性能的线程

我优化了一下查询。但我得到的真正速度是将datetime列更改为datetime2。

现在，以前超时的同一个查询只需要不到一秒钟的时间。

干杯

MSDN datetime文档建议使用datetime2。以下是他们的建议：

使用time、date、datetime2和新的datetimeoffset数据类型工作这些类型与SQL一致标准它们更便于携带。time、datetime2和datetimeoffset提供更多的秒精度。datetimeoffset提供时区支持全球部署应用。

datetime2具有更大的日期范围、更大的默认小数精度和可选的用户指定精度。还取决于用户指定的精度，它可能使用更少的存储空间。