根据本文，如果您希望使用DateTime2获得与DateTime相同的精度，则只需使用DateTime1（3）。这将为您提供相同的精度，占用更少的字节，并提供扩展的范围。

datetime2在除（旧应用兼容性）之外的大多数方面都获胜

较大的值范围更好的准确性较小的存储空间（如果指定了可选的用户指定精度）

请注意以下几点

语法datetime2[（小数秒精度=>低于存储大小）]精度，刻度0至7位，精度为100ns。默认精度为7位数。存储大小精度小于3时为6字节；精度3和4为7字节。所有其他精度要求8字节。DateTime2（3）的位数与DateTime相同，但使用7字节的存储，而不是8字节（SQLHINTS-DateTime Vs DateTime2）查找有关datetime2的详细信息（Transact-SQL MSDN文章）

图像来源：MCTS自学训练套件（考试70-432）：Microsoft®SQL Server®2008-实施和维护第3章：表格->第1课：创建表格->第66页

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

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

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

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

我同意@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公司

几乎所有的答案和评论都是赞成者居多，反对者较少。这里是到目前为止所有优点和缺点的总结，以及一些关键缺点（在下面的#2中），我只见过一次或根本没有提到。

赞成的意见：

1.1.更符合ISO（ISO 8601）（尽管我不知道这在实践中是如何发挥作用的）。

1.2.更多的范围（1/1/0001至12/31/9999与1/1/175-32/31/9999）（尽管1753年之前的额外范围可能不会被使用，但历史、天文、地质等应用程序除外）。

1.3.与.NET的DateTime Type的范围完全匹配（尽管如果值在目标类型的范围和精度范围内（以下Con#2.1除外，否则将发生错误/舍入），则两者都可以进行来回转换，无需特殊编码）。

1.4更高的精度（100纳秒，即0.0000000,1秒，而3.33毫秒，即0.003,33秒）（尽管除了工程/科学应用程序外，可能不会使用额外的精度）。

1.5.当配置为与DateTime的精度类似（如Iman Abidi所宣称的1毫秒，而不是“相同”（如3.33毫秒））时，使用的空间更少（7字节对8字节），但当然，您将失去精度优势，这可能是最受吹捧的两个（另一个是范围）之一，尽管可能是不必要的优势）。

欺骗：

2.1.将参数传递给.NET SqlCommand时，如果传递的值超出了SQL Server DateTime的范围和/或精度，则必须指定System.Data.SqlDbType.DateTime2，因为它默认为System.Data.SqlDbType.Date Time。

2.2.无法隐式/轻松地转换为浮点数字（自最小日期时间起的天数）值，以便在SQL Server表达式中使用数值和运算符对其执行以下操作：

2.2.1增加或减少天数或部分天数。注意：当您需要考虑日期时间的多个部分（如果不是全部的话）时，使用DateAdd函数作为一种解决方法并不简单。

2.2.2.为了计算“年龄”，取两个日期时间之间的差值。注意：您不能简单地使用SQL Server的DateDiff函数，因为它不会像大多数人预期的那样计算年龄，因为如果两个日期时间恰好跨越指定单位的日历/时钟日期时间边界，即使是该单位的一小部分，它也会返回该单位的1与0之间的差值。例如，如果两个日期时间在不同的日历日（即“1999-12-31 23:59:59.9999999”和“2000-01-01 00:00:00.0000000000”），则仅相隔1毫秒的日期时间的Day中的DateDiff将返回1与0（天）。如果移动相同的1毫秒差的日期时间，使其不跨越日历日，则Day中返回0（天”的“DateDiff”。

2.2.3.通过先转换为“浮点”，然后再转换为DateTime，获取日期时间的平均值（在聚合查询中）。

注意：要将DateTime2转换为数字，您必须执行以下公式，该公式仍然假设您的值不小于1970年（这意味着您将失去所有额外范围加上217年）。注意：您可能无法简单地调整公式以允许额外范围，因为您可能会遇到数字溢出问题。

25567+（DATEDIFF（SECOND，｛d'1970-01-01'｝，@Time）+DATEPART（纳秒，@Time）/1.0E+9）/86400.0–来源：“https://siderite.dev/blog/how-to-translate-t-sql-datetime2-to.html “

当然，您也可以先转换为DateTime（如果需要，再转换为DateTime2），但您会失去DateTime2与DateTime2相比的精度和范围（在1753年之前）的优势。DateTime是最大的2个，同时也是最不可能需要的2个。这就引出了这样一个问题：当您丢失了对浮点数字（天数）的隐式/简单转换时，为什么要使用它进行加法/减法/“年龄”（与DateDiff相比）/平均计算，这在我的经验中是一个很大的好处。

顺便说一句，日期时间的平均值是（或者至少应该是）一个重要的用例。a） 除了在使用日期时间（由于通用基准日期时间）表示持续时间（一种常见做法）时用于获取平均持续时间外，b）还可以获得一个仪表板类型的统计信息，该统计信息显示行范围/行组的日期时间列中的平均日期时间。c） 一个标准（或至少应该是标准）的特殊查询，用于监视/排除列中可能不再有效和/或可能需要弃用的值，即列出每个值的出现计数以及与该值关联的最小、平均和最大日期时间戳（如果可用）。