Right now, the _currentCommittedSnapshot, which is used as the optime for majority readers, is stored as an OpTimeAndWallTime type. After the removal of the stable optime candidates list in PM-1713, however, this value may no longer be sourced from a real oplog optime, so it may not have a "real" wall clock time. To work around this, we give it a dummy wall clock time when we construct it. The wall clock time of the committed snapshot shouldn't serve any functional purpose in the server, since flow control calculations use the lastCommittedOpTime. It is, however, still reported as the readConcernMajorityOpTime in replSetGetStatus. If we determine that there is no significant value in reporting an accurate wall clock time for the readConcernMajorityOpTime, then we should be able to convert the currentCommittedSnapshot to an OpTime type, to prevent confusion in the code.

Note that the committed snapshot was originally converted to include a wall clock time in SERVER-34598. Presumably having lastApplied/lastDurable and the lastCommittedOpTime with wall clock information in replSetGetStatus should still be sufficient to satisfy that ticket's goals.