A bug in conversion of milliseconds

[or-else]

Rethink stores time as a floating point number with precision to milliseconds. Go's native time has precision to nanoseconds. The gorethink's conversion of time from float64 milliseconds to time.Time creates artifacts in microseconds and nanoseconds. With the current code every time.Time fetched from RethinkDB must be rounded to milliseconds if consistency of stored vs retrieved value is important. It makes sense to do correct rounding in the driver. The fix ensures that the time is consistent.

[or-else]

The failing test makes no sense to me. It asserts that
[1986-11-03 12:30:15.67900002] is equal to [1986-11-03 12:30:15.679] which is only possible if the fact of storing [1986-11-03 12:30:15.679] in the database converts it to [1986-11-03 12:30:15.67900002]
It asserts incorrect behavior.

[dancannon]

The failing test is due to the hacky way the test was originally implemented https://github.com/dancannon/gorethink/blob/master/query_time_test.go#L26. With your fix this is no longer needed so the test could probably be changed to:

c.Assert(response.Equal(time.Date(1986, 11, 3, 12, 30, 15, 679*1000*1000, time.UTC)), test.Equals, true)

Would it be possible for you to include that in your PR?

[or-else]

I made a change to the call to Time to assert that precision beyond milliseconds is correctly stripped.

[ianberinger]

I stumbled over this too. For what it's worth, I rounded the time value with time.Round(time.Millisecond) in my code. Your changes look good though.

[dancannon]

time.Round seems like a simpler solution (I didn't realise that function existed haha).

What do you think @or-else?

[or-else]

Actually that was my first attempt:
t := time.Unix(int64(sec), int64(ms*1000*1000*1000)).Round(time.Millisecond)
but then it seemed suboptimal - first construct incorrect value, then fix it.

[dancannon]

Ok makes sense, one last question (and this is just me being slow) why are you adding 0.5 before rounding?

[or-else]

It ensures correct rounding, math.Floor rounds down. See here:
https://play.golang.org/p/AijkNZjEzY

[or-else]

Also see discussion here: golang/go#4594

[dancannon]

Merged, thanks again for both the PR and for dealing with all my questions!