[CSHARP-114] DateTime data types are off by a few ticks Created: 25/Nov/10  Updated: 02/Apr/15  Resolved: 01/Dec/10

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: None
Fix Version/s: 0.7

Type: Bug Priority: Minor - P4
Reporter: Ed Rooth Assignee: Robert Stam
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win Server 2008.
.NET 3.5



 Description   

Create a date, save it, retrieve it back and the DateTime.CompareTo() function says that they are not equal. All inner fields are equal except for the Ticks field.

Not sure if it matters, but doing everything in SafeMode, and the date property is decorated with [BsonDateTimeOptions(Kind = DateTimeKind.Local)].

Steps to reproduce:
-------------------------------

var myItem = new Item(...);

var myDate = DateTime.Now;
myItem.date = myDate;

// this assert is passes.
Assert.AreEqual(0, myDate.CompareTo(myItem.date));

myCollection<Item>.Save(myItem, SafeMode.True);

// query the db to get the same object that is myItem.
var savedAndRetrievedMyItem = myCollection.FindOneAs(...);

// this assert fails.
Assert.AreEqual(0, myDate.CompareTo(savedAndRetrievedMyItem.date));



 Comments   
Comment by Robert Stam [ 01/Dec/10 ]

Closed.

Comment by Ed Rooth [ 26/Nov/10 ]

Robert, thanks for clearing that up.

For our purposes it's not really a big deal. I was just surprised when the CompareTo() function didn't work as expected. As long as this is well documented and understood by the users I think the current implementation is fine.

However it is imaginable that this may cause issues for some scientific or financial applications.
Either way, it's still low priority in my opinion.

Comment by Robert Stam [ 25/Nov/10 ]

.NET's DateTime values have a resolution of 100 nanoseconds per tick, but the BSON representation for a DateTime has a resolution of 1 millisecond. So when a .NET DateTime is stored in BSON some of the low order bits are lost.

Do you think we need a way to store .NET DateTime's without loss of precision? Some possible alternatives are:

1. Add an option to store a .NET DateTime as a BSON Int64 and store the Ticks
2. Add an option to store a .NET DateTime as a BSON document like:

{ 'DateTime': bsonDateTime, 'LowOrderTicks' : 123 }

Not sure this is worth addressing. SQL Server has a similar issue where its internal representation of a DateTime is not quite as precise as .NET's, and I think most people just accept that.

Will probably end up closing this ticket as works as designed, but will leave it open a bit longer in hopes of more comments.

Comment by Robert Stam [ 25/Nov/10 ]

Changed component to Driver.

Generated at Wed Feb 07 21:35:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.