In several places in the codebase, timestamps are used to determine the order of edits and other actions, which can lead to issues in situations where several actions happen at nearly the same time. One example of this is countRevisionsBetween in Title.php. If multiple revisions of a page are made within 2 seconds, it will return an incorrect count when used on those revisions. Shouldn't this and all similar uses be changed to compare based on the table's primary key instead (revision ID in this case)?
|Duplicate||None||T86785 Excessive quantity of edits conflict in a busy project page|
|Open||None||T113004 Make it easy to fork, branch, and merge pages (or more)|
|Open||None||T72163 Edit conflicts (tracking)|
|Open||None||T61609 Over-reliance on timestamps can lead to incorrect counts|
|Open||None||T61694 Edit form should keep track of what the latest revision was when editing began|
The reason our code often uses timestamps (instead of primary keys) is because revisions can be inserted out of sequence. Most commonly as a result of importing revisions and pages via Special:Import.
It may also happen as result of a history merge (unsure?).
Timestamps tend be to be preferred because they match the way we view revisions on the history page.
As described, I think the task should be declined. But it would be reasonable to extend the resolution of timestamps to the point where they are unique, for example, using a time UUID like UIDGenerator::newTimestampedUID88(). Revision IDs are not monotonic in time and should never be used to select ranges for display.