当我插入这些值时
09/30/2013 05:04:56.599
09/30/2013 05:04:56.599
09/30/2013 05:04:56.599
09/30/2013 05:04:57.082
在SqlServer数据库中,毫秒值以奇怪的方式改变
2013-09-30 05:04:56.600
2013-09-30 05:04:56.600
2013-09-30 05:04:56.600
2013-09-30 05:04:57.083
怎么了?
编辑: 相关代码:
com = new SqlCommand();
com.Connection = con;
com.CommandText = @"INSERT INTO [AuthSourceTimings]
([FileName]
,[JobID]
,[JobCreationTime]
,[JobSendTime]
,[JobAckTime]
,[JobDoneTime])
VALUES
(@FileName
,@JobID
,@JobCreationTime
,@JobSendTime
,@JobAckTime
,@JobDoneTime)
";
com.Parameters.AddWithValue("@FileName", fileName);
com.Parameters.AddWithValue("@JobID", t.JobID);
com.Parameters.AddWithValue("@JobCreationTime", t.JobCreationTime == DateTime.MinValue ? (object)DBNull.Value : (object)t.JobCreationTime);
com.Parameters.AddWithValue("@JobSendTime", t.JobSendTime == DateTime.MinValue ? (object)DBNull.Value : (object)t.JobSendTime);
com.Parameters.AddWithValue("@JobAckTime", t.JobAcknowledgementTime == DateTime.MinValue ? (object)DBNull.Value : (object)t.JobAcknowledgementTime);
com.Parameters.AddWithValue("@JobDoneTime", t.JobCompletionTime == DateTime.MinValue ? (object)DBNull.Value : (object)t.JobCompletionTime);
com.ExecuteNonQuery();
答案 0 :(得分:6)
毫秒数的存储时间仅为日期时间格式的1/300秒精度,这是不准确的来源。
您可以查看以下答案:Why is SQL Server losing a millisecond?
要获得更高的精度(100纳秒),您可以使用SQL Server 2008中引入的DATETIME2
。您可以在此处获取更多信息:
答案 1 :(得分:5)
您可能正在使用SQL Server类型DATETIME
,文档声明:
Rounded to increments of .000, .003, or .007 seconds.
如果您想要与.NET DATETIME2
完全兼容,则应使用DateTime
类型。这两个都具有100纳秒的精度。
使用DATETIME
的好理由不多了。 DATETIME2(7)
占用8个字节,与DATETIME
相同,但具有更高的准确度和范围。 DATETIME2(3)
占用6个字节,仍然具有更好的准确性(3个小数,没有上面详述的奇怪的舍入行为)。
答案 2 :(得分:1)
一切都与精确有关。如果您在数据库中使用datetime类型,请尝试datetime2类型。
答案 3 :(得分:0)
答案 4 :(得分:0)
非常清楚,它不是.NET
或代码问题
DECLARE @TestDateFrom DATETIME='2010-06-29 05:04:56.599'
SELECT @TestDateFrom
结果
2010-06-29 05:04:56.600
并且对Szymon的回答满意“毫秒数的存储时间仅为日期时间格式的1/300秒精度,这是不准确的地方。”