Reverting to a document version creates a new one

When rolling back a document to a previously stored state, a new revision at the current date and time is created. For rolling back in time, where we also want to roll back edit times, and have this represented in document lists, could we imagine a sort of "hack" that creates a new "version forked" / "version restored" commit, *and* have the modification timestamp list the previous version? Maybe the thread where one was thinking out loud on Twitter about timestamps at and before has something to add here? > • atime is last time opened &/ written • mtime is last time *document state* changed • ctime is last time *document metadata* changed I wonder where this differentiation could lead next. Which other cases could profit from this kind of timestamping? • Real-time documents, which haven't persisted to server, yet? • As such intermediary versions (mtime), which lie between global sync (ctime…