-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Diagnostics
-
Fully Compatible
-
ALL
-
Platform 9 (09/18/15)
Capturing samples, encoding, and decoding, all through the support tooling (POC) implementation, we get the following output after decoding for the replica set "optime" timestamps; the "t" fields of the "optime" field contain Unix epoch times that match the "optimeDate" fields:
"localTime" : { "$date" : "2015-09-17T13:56:00.013-0400" }" "optime" : { "$timestamp" : { "t" : 1442512560, "i" : 2674 } }, "optimeDate" : { "$date" : "2015-09-17T13:56:00.000-0400" } "optime" : { "$timestamp" : { "t" : 1442512524, "i" : 75913 } }, "optimeDate" : { "$date" : "2015-09-17T13:55:24.000-0400" }
Capturing samples and encoding using the server implementation, and then decoding through the support tooling decoder we get the following (for a sample captured at about the same time):
"localTime" : { "$date" : "2015-09-17T13:56:00.000-0400" }, "optime" : { "$timestamp" : { "t" : 1442580230, "i" : 189973 } }, "optimeDate" : { "$date" : "2015-09-17T13:55:59.000-0400" }, "optime" : { "$timestamp" : { "t" : 1442588416, "i" : 75913 } }, "optimeDate" : { "$date" : "2015-09-17T13:55:24.000-0400" },
The "t" fields of the "optime" timestamp don't match the "optimeDate" fields, and are off by about 70k seconds.