|
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.
|