To address different versions of your data with pgMemento you have to think in transactions, not timestamps. Although, each transaction is logged with a timestamp, you still need to know its ID to filter the data changes. Especially when dealing with concurrent edits filtering only by timestamps could produce inconsistent views. Establishing versions based on transactions will produce a state of the data as the user has seen it when he applied the changes.
So, when pgMemento provides a function where the user can determine the state he wants to restore by passing a transaction id it addresses the version BEFORE the transaction excluding the changes of this transaction!
Nevertheless, as most users of an audit trail solution probably want to use timestamps to query the history of their database, they could get the next transaction id found after a given timestamp with this query:
stmt_date >= '2018-10-26 16:00:00'