[JAVA-634] BSONTimestamp loses precision Created: 29/Aug/12 Updated: 30/Aug/12 Resolved: 29/Aug/12 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | API |
| Affects Version/s: | 2.9.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Tal Liron | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
For a reason unfathomable to me, the API for BSONTimestamp uses seconds, both for the constructor and for getTime(), even though the actual BSON type is in milliseconds. Since the type is an integer, this means that any millisecond precision is lost in the Java driver. Please fix this to use milliseconds! For backwards API compatibility, I suggest the following: 1. A second constructor: BSONTimestamp(int t, int i, boolean isMilliseconds) - the old constructor would just call this with isMilliseconds=false |
| Comments |
| Comment by Tal Liron [ 29/Aug/12 ] |
|
Many thanks, and glad I contributed to a clarification. I will update the code for the Rhino JavaScript driver (which I maintain) to reflect this, as it currently uses milliseconds. |
| Comment by Scott Hernandez (Inactive) [ 29/Aug/12 ] |
|
The extended json docs were wrong. Now fixed. We have no plans to extent the type, or change it in the immediate future. |
| Comment by Tal Liron [ 29/Aug/12 ] |
|
Oh, interesting, I was looking at the extended JSON spec for $timestamp where it mentions that "i" is a 32-bit integer measured in milliseconds. I guess this is just in preparation for a future improvement in precision? If so, it might be nice to have the Java driver also prepare the future by allowing the APIs I mentioned, even though no precision is lost. That way code that relies on it will gain this benefit in the future. |
| Comment by Scott Hernandez (Inactive) [ 29/Aug/12 ] |
|
The bson timestamp is 8 bytes where 4bytes are in seconds and 4bytes are a counter. It is not stored in milliseconds. |