毫秒在我的DateTime更改时，存储在SQL Server

本文关键字：存储 SQL Server 我的 DateTime | 更新日期: 2023-09-27 18:11:37

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

DateTime myDateTime = DateTime.Now;

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

当它进入TimeOfDay值时:09:30:03.0196095

输出时TimeOfDay值为:09:30:03.0200000

这样做的最终效果是，保存前的毫秒数为19，重新加载后的毫秒数为20。

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

SQL Server没有。net那么精确吗?或者是实体框架或OData搞砸了这个?

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

毫秒在我的DateTime更改时，存储在SQL Server

这取决于你使用的SQL server的版本。

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

在你的例子中，09:30:03.0196095被四舍五入到09:30:03.020。

从SQL 2008开始，添加了其他数据类型以提供更多细节，例如datetime2，它有多达7位的小数点，精度在100ns以内。

查看更多信息:

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

我认为你最好的选择是提供舍入到秒之前存储在SQL服务器，如果毫秒是不重要的。

这是由于SQL datetime类型的精度。根据msdn:

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

查看此msdn页面的 datetime小数秒精度的舍入部分，您将了解舍入是如何完成的。

根据其他人的指示，您可以使用datetime2而不是datetime来获得更好的精度:

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

对于那些没有能力在SQL中使用DateTime2的人(例如:像我这样使用由单独系统生成的表，对于单个问题进行更改将是昂贵的)，有一个简单的代码修改将为您进行舍入。

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

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

这将把值转换成SQL刻度，然后再转换回。net刻度，包括精度的损失。:)

一个警告，这将失去原DateTime结构(即Utc, Local)的Kind。这种转换也不是简单的舍入，有一个完整的转换，包括刻度计算，MaxTime的变化等。因此，如果您依赖DateTime中的特定指标，则不要使用此功能，因为它们可能会丢失。

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

相关文章：