Magnus Manske wrote:
For [[Oxygen]], the first edit logged in the database is mine, September 15, *2001*. However, when you click on it:
http://en.wikipedia.org/w/index.php?title=Oxygen&oldid=271622
be surprised to find a link to "older version", pointing to an edit from September 2, *2002*:
http://en.wikipedia.org/w/index.php?title=Oxygen&direction=prev&oldi...
When you keep following the "older version" trail, you'll end up at the conversion script edit of February 12, *2002*:
http://en.wikipedia.org/w/index.php?title=Oxygen&direction=prev&oldi...
I vaguely remember a version-order bug from ancient times. Is that the same one?
Timestamps have one-second resolution and so are not unique. So ordering by timestamp, "SELECT rev_id FROM revision WHERE rev_timestamp<$t ORDER BY rev_timestamp DESC LIMIT 1" to find a previous revision introduces bugs, because faced with non-unique timestamps, it would skip revisions. This is the algorithm used by the prev/next links on the history page.
Another way to find a previous revision is to order by rev_id. But rev_id is not monotonic with respect to time, due to various accidents of history. There are step discontinuities, such as those introduced by undeletion or the conversion script. It is however used by the older/newer links on the old revision views. This algorithm is chosen over the timestamp algorithm because at the time the revision is fetched, the timestamp is not known, only the rev_id is known. Finding out the timestamp would require an extra query.
Neither rev_timestamp nor rev_id provides a way to order revisions precisely. The way to do it properly is to use the rev_id only to resolve conflicts when multiple revisions share the requested page/timestamp pair. Unfortunately this is slower and more complex than either of the other two methods.
-- Tim Starling