[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. |
||
| 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; // this assert is passes. myCollection<Item>.Save(myItem, SafeMode.True); // query the db to get the same object that is myItem. // this assert fails. |
| 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. |
| 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 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. |