This project has moved and is read-only. For the latest updates, please go here.

BSON DateTime precision

May 9, 2010 at 5:16 PM

With DateTime we are loosing precision (Ticks) and we are "self" managing the DateTime.Kind.

Perhaps, for BSON, we can use DateTime.ToBinary() and serialize/deserialize its value (a long).

Using ToBinary/FromBinary method we can fit two exigence :

1) don't loose precision

2) don't worry about the Kind of DateTime specified in the reader ctor

Thought ?

May 9, 2010 at 11:19 PM

The BSON spec specifies that a datetime is UTC since the Unix epoc (1970).

May 10, 2010 at 12:08 AM

UTC milliseconds... I know.

Ok, thanks you.

Aug 5, 2010 at 12:18 AM

Milliseconds isn't the Issue, it's ticks precision.

For instance if you create a new date:

var date1 = DateTime.Now; // date1.Ticks = 634165352561329529

and then you serialize / deserialize it back into a date, then you get:

// date2.Ticks = 634165352561320000

basically the 10000's are being lost from ticks precision.

so date1 != date2 // because the Equals override on DateTime uses Ticks.


I just ran into this problem on a unit test.


Aug 5, 2010 at 4:32 AM

I'm not going to change the default behavior because I want to follow the spec but you could write a JsonConverter that serializes/deserializes a DateTime as its Int64 ticks.

Aug 5, 2010 at 8:30 PM

I agree.  You should follow the spec, which has smallest granularity at milliseconds.  We could always expose the ticks as an Int64 property if that resolution is required.