Storing time.Duration as nanoseconds about mgo HOT 2 CLOSED

The bson spec defines datetime specifications as milliseconds. Even though duration doesn't necessarily equate to a datetime representation, it may be good for mgo to utilize the same datatype (int64). One thing you could do is wrap your time.Duration in a different type which supports custom BSON marshaling/unmarshaling.

Though others may have different opinions, I personally feel that time.Duration probably shouldn't be truncated to an int64 (milliseconds), because loss of accuracy/precision in regards to time is a huge issue, esp. when talking about a duration. I feel nanoseconds may have been a better choice, because I think it is still a very common unit to use, whereas something smaller like picoseconds aren't.

In any case, now that this has already been implemented, I don't think it can be reversed without causing lots of issues for others.

from mgo.

Hi @TeoV,

@lrstanley's fantastic explanation is right - ideally it should be as precise as possible (especially as we're throwing away precision in this case!) but the original mgo code uses milliseconds so it would be a breaking change, not necessarily for mgo users, but it would definitely break any consumers of the stored data using a different language/driver.

You could experiment with wrapping a time.Time with a custom type in your storage layer as suggested - it's the best way to get what you're after off the top of my head.

Sorry!
Dom

from mgo.