我认为DATETIME2是存储日期的更好方法，因为它比DATETIME。在SQL Server 2008中，您可以使用DATETIME2，它存储日期和时间，需要6-8个字节，精度为100纳秒。因此，任何需要更高时间精度的人都会想要DATETIME2。

虽然datetime2提高了精度，但有些客户端不支持date、time或datetime2，并强制您转换为字符串文本。微软特别提到了ODBC、OLE DB、JDBC和SqlClient这些数据类型的“底层”问题，并有一个图表显示了它们如何映射类型。

如果值兼容性超过精度，请使用datetime

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

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

我同意@marc_s和@Adam_Poward的观点——DateTime2是前进的首选方法。它的日期范围更广，精度更高，使用的存储量相等或更少（取决于精度）。

然而，讨论中遗漏了一件事。。。@Marc_s状态：这两种类型都映射到.NET中的System.DateTime-没有区别。这是正确的，然而，相反的是不正确的。。。在进行日期范围搜索时很重要（例如“查找2010年5月5日修改的所有记录”）。

.NET版本的Datetime具有与DateTime2相似的范围和精度。将.net Datetime向下映射到旧的SQL Datetime时，会发生隐式舍入。旧的SQL DateTime精确到3毫秒。这意味着11:59:59.997将尽可能接近一天的结束。任何更高的值都将舍入到第二天。

试试看：

declare @d1 datetime   = '5/5/2010 23:59:59.999'
declare @d2 datetime2  = '5/5/2010 23:59:59.999'
declare @d3 datetime   = '5/5/2010 23:59:59.997'
select @d1 as 'IAmMay6BecauseOfRounding', @d2 'May5', @d3 'StillMay5Because2msEarlier'

避免这种隐式舍入是转移到DateTime2的一个重要原因。日期的隐式舍入显然会引起混淆：

SQL Server中奇怪的日期时间行为http://bytes.com/topic/sql-server/answers/578416-weird-millisecond-part-datetime-data-sql-server-2000-aSQL Server 2008和毫秒http://improve.dk/archive/2011/06/16/getting-bit-by-datetime-rounding-or-why-235959-999-ltgt.aspxhttp://milesquaretech.com/Blog/post/2011/09/12/DateTime-vs-DateTime2-SQL-is-Rounding-My-999-Milliseconds!.aspx公司

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

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

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

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

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