存储在 SQL Server 中时，我的 DateTime 中的毫秒数会发生变化答案

【问题标题】：Milliseconds in my DateTime changes when stored in SQL Server存储在 SQL Server 中时，我的 DateTime 中的毫秒数会发生变化
【发布时间】：2011-10-19 15:39:30
【问题描述】：

我有一个这样生成的日期时间：

DateTime myDateTime = DateTime.Now;

然后，我使用实体框架将其存储在数据库中（在DateTime 类型的列中）。然后我使用 OData（WCF 数据服务）检索它。

当它进入 TimeOfDay 值是：09:30:03.0196095

当它出来时，TimeOfDay 值为：09:30:03.0200000

这样做的最终结果是，毫秒在保存之前被视为 19，在重新加载后被视为 20。

所以当我稍后在我的代码中进行比较时，它会在应该相等的地方失败。

SQL Server 的精度是否不如 .NET？还是实体框架或 OData 搞砸了？

我将截断毫秒（我真的不需要它们）。但我想知道为什么会这样。

【问题讨论】：

你是怎么比较的？
这是不同的精度。请参阅旁边的相关问题。
您使用的是哪个版本的 SQL Server？如果 2008 datetime2 精度更高。
仅仅截断 ms 可能还不够。您可以将 09:30:03.999999 舍入为 09:30:04.000000
@Joel - 在我第一次将它保存在数据库中之前，我将缩短几毫秒。这样第二次就会匹配。

标签： c# .net sql-server

【解决方案1】：

这实际上取决于您使用的 SQL Server 版本。

日期时间字段的分辨率为小数点后 3 位：例如：2011-06-06 23:59:59.997，仅精确到 3.33 毫秒以内。

在您的情况下，09:30:03.0196095 在存储上被四舍五入到 09:30:03.020。

从 SQL 2008 开始，添加了其他数据类型以提供更多详细信息，例如 datetime2，它最多有 7 位小数，精确到 100ns 以内。

有关详细信息，请参阅以下内容：

http://karaszi.com/the-ultimate-guide-to-the-datetime-datatypes

如果毫秒不重要，我认为最好的办法是在将第二个 PRIOR 存储在 SQL 服务器之前提供舍入。

【讨论】：

【解决方案2】：

这是由于 SQL datetime 类型的精度造成的。根据msdn：

日期时间值以 0.000、0.003 或 0.007 秒的增量四舍五入

查看this msdn page 的日期时间小数秒精度的舍入部分，您将了解如何进行舍入。

正如其他人所指出的，您可以使用datetime2 而不是datetime 以获得更好的精度：

datetime时间范围为00:00:00 through 23:59:59.997
datetime2时间范围为00:00:00 through 23:59:59.9999999

【讨论】：

datetime2 对我来说仍然以同样的方式舍入毫秒小数。为什么？？

【解决方案3】：

对于那些不能在 SQL 中使用 DateTime2 的人（例如：像我一样使用由单独系统生成的表，对于这个单一问题进行更改会很昂贵），有一个简单的代码修改将为你做四舍五入。

引用 System.Data 并导入 System.Data.SqlTypes 命名空间。然后您可以使用SqlDateTime 结构为您进行转换：

DateTime someDate = new SqlDateTime(DateTime.Now).Value;

这会将值转换为 SQL 刻度，然后再转换回 .NET 刻度，包括精度损失。 :)

一句警告，这将丢失原始DateTime 结构的Kind（即Utc、Local）。这种转换也不是简单的四舍五入，还有一个完整的转换，包括刻度计算、MaxTime 变化等。所以如果你依赖DateTime 中的特定指标，请不要使用它，因为它们可能会丢失。

【讨论】：

【解决方案4】：

SQL Server 中 DateTime 的精度为毫秒 (.fff)。所以 0.0196 将四舍五入为 0.020。如果您可以使用datetime2，您将获得更高的精度。

【讨论】：

唉，OData 不支持 DateTime2。所以我不能使用它。